Add a new EHCI driver for Broadcom STB SoC's. A new EHCI driver
was created instead of adding support to the existing ehci platform
driver because of the code required to workaround bugs in the EHCI
controller. The primary workround is for a bug where the Core
violates the SOF interval between the
Add the build system changes needed to get the Broadcom STB XHCI,
EHCI and OHCI functionality working. The OHCI support does not
require anything unique to Broadcom so the standard ohci-platform
driver is being used. Also update MAINTAINERS.
Signed-off-by: Al Cooper
---
MAINTAINERS
Some BRCMSTB USB chips have an XHCI, EHCI and OHCI controller
on the same port where XHCI handles 3.0 devices, EHCI handles 2.0
devices and OHCI handles <2.0 devices. Currently the Makefile
has XHCI linking at the bottom which will result in the XHIC driver
initalizing after the EHCI and OHCI
Add support for Broadcom STB SoC's to the xhci platform driver
Signed-off-by: Al Cooper
Acked-by: Mathias Nyman
---
drivers/usb/host/xhci-plat.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/drivers/usb/host/xhci-plat.c b/drivers/usb/host/xhci-plat.c
index
On Thu, 7 May 2020 13:28:28 -0400
Steven Rostedt wrote:
> > It's perfectly safe to return 0/1 in a boolean function; that said seeing
> > as this is the second attempt at "fixing" this I'm tempted to say we should
> > pick it up...
> >
>
> Actually, I disagree. We should push back on the
On Thu, May 07, 2020 at 10:09:03AM -0700, Paul E. McKenney wrote:
> On Thu, May 07, 2020 at 01:00:06PM -0400, Johannes Weiner wrote:
> > On Wed, May 06, 2020 at 05:55:35PM -0700, Andrew Morton wrote:
> > > On Wed, 6 May 2020 17:42:40 -0700 "Paul E. McKenney"
> > > wrote:
> > >
> > > > This
> On May 7, 2020, at 1:16 PM, Catalin Marinas wrote:
>
> I don't mind adding additional tracking info if it helps with debugging.
> But if it's for improving false positives, I'd prefer to look deeper
> into figure out why the pointer reference graph tracking failed.
No, the task struct
On Thu, 07 May 2020 12:17:36 +0100
Valentin Schneider wrote:
> On 07/05/20 12:06, Jason Yan wrote:
> > Fix the following coccicheck warning:
> >
> > kernel/sched/fair.c:9375:9-10: WARNING: return of 0/1 in function
> > 'voluntary_active_balance' with return type bool
> >
>
> It's perfectly
On 5/7/20 12:23 PM, Joe Perches wrote:
On Thu, 2020-05-07 at 12:08 -0500, himanshu.madh...@oracle.com wrote:
On 5/7/20 11:57 AM, Joe Perches wrote:
On Thu, 2020-05-07 at 11:12 -0500, Himanshu Madhani wrote:
I do not have access to my @marvell.com email ID anymore.
Lets map my new email
On Thu, May 7, 2020 at 4:26 PM Jeremy Linton wrote:
> On 5/5/20 8:29 AM, Calvin Johnson wrote:
> > + if (sscanf(cp, "ethernet-phy-id%4x.%4x",
> > +, ) == 2) {
> > + *phy_id = ((upper & 0x) << 16) | (lower & 0x);
> > +
I do not have access to my @marvell.com email ID anymore.
Lets map my new email address correctly in .mailmap
Signed-off-by: Himanshu Madhani
---
Changes from v1
- Update patch subject line to reflect .mailmap changes.
---
.mailmap | 2 ++
1 file changed, 2 insertions(+)
diff --git a/.mailmap
On Fri, 8 May 2020 00:50:28 +0900
Masami Hiramatsu wrote:
> > > Yes, I need Tom's review for this change. As far as I can test, this
> > > fixes the test failure. If this isn't acceptable, we can use "alias
> > > echo=echo"
> > > for this test case.
> > >
> >
> > I still don't see how
On Thu, 7 May 2020, Randy Dunlap wrote:
> > Changes since 20200505:
> >
>
>
> on i386 or x86_64:
>
> ERROR: modpost: "usb_hid_driver" [drivers/hid/hid-asus.ko] undefined!
> or
> (when builtin:)
> ld: drivers/hid/hid-asus.o: in function `asus_probe':
> hid-asus.c:(.text+0x60f): undefined
With dmtimer and 32k counter being initialized based on devicetree data,
we can just drop the old timer code.
This still leaves the omap5 and dra7 realtime_counter_init() that
depend on the smc calls and control module platform code for the dra7
quirk init.
Cc: Grygorii Strashko
Cc: Keerthy
On Thu, May 7, 2020 at 9:46 AM Arnaldo Carvalho de Melo
wrote:
>
> Em Thu, Apr 30, 2020 at 09:38:34PM +0800, Jin, Yao escreveu:
> > Hi John, Jiri,
> >
> > On 4/30/2020 7:48 PM, John Garry wrote:
> > > On 30/04/2020 12:15, Jiri Olsa wrote:
> > >
> > > +
> > >
> > > > On Thu, Apr 30, 2020 at
We can now init system timers using the dmtimer and 32k counter
based on only devicetree data and drivers/clocksource timers.
Let's configure the clocksource and clockevent, and drop the old
unused platform data.
As we're just dropping platform data, and the early platform data
init is based on
We can now init system timers using the dmtimer and 32k counter
based on only devicetree data and drivers/clocksource timers.
Let's configure the clocksource and clockevent, and drop the old
unused platform data.
As we're just dropping platform data, and the early platform data
init is based on
We can now init system timers using the dmtimer and 32k counter
based on only devicetree data and drivers/clocksource timers.
Let's configure the clocksource and clockevent, and drop the old
unused platform data.
As we're just dropping platform data, and the early platform data
init is based on
As timers no longer need legacy quirk handling, let's move them to
the CONFIG_DEBUG section to make it easier to see which drivers still
need more work.
Let's also add detection for few more older timer revisions while at
it as that makes CONFIG_DEBUG output easier to read with proper names.
Cc:
We can now init system timers using the dmtimer and 32k counter
based on only devicetree data and drivers/clocksource timers.
Let's configure the clocksource and clockevent, and drop the old
unused platform data.
As we're just dropping platform data, and the early platform data
init is based on
Let's allow probing the 32k counter directly based on devicetree data to
prepare for dropping the related legacy platform code. Let's only do this
if the parent node is compatible with ti-sysc to make sure we have the
related devicetree data available.
Let's also show the 32k counter information
We can move the TI dmtimer clockevent and clocksource to live under
drivers/clocksource if we rely only on the clock framework, and handle
the module configuration directly in the clocksource driver based on the
device tree data.
This removes the early dependency with system timers to the
We can now init system timers using the dmtimer and 32k counter
based on only devicetree data and drivers/clocksource timers.
Let's configure the clocksource and clockevent, and drop the old
unused platform data.
As we're just dropping platform data, and the early platform data
init is based on
Some early omap3 boards use timer12 for system timer, but for secure
SoCs like on n900 it's not accessible. Likely we will be configuring
unavailable devices for other SoCs too based on runtime SoC detection,
so let's use a switch to start with.
Cc: Grygorii Strashko
Cc: Keerthy
Cc: Lokesh
Hi all,
Here's v3 series to udpate omaps to use drivers/clocksource timers for
the 32k counter and dmtimer, and to remove the old legacy platform code.
Please review and test.
I've updated the timer-ti-dm-systimer.c patch based on the comments from
Daniel and Rob, and added support for selecting
We can now init system timers using the dmtimer and 32k counter
based on only devicetree data and drivers/clocksource timers.
Let's configure the clocksource and clockevent, and drop the old
unused platform data.
As we're just dropping platform data, and the early platform data
init is based on
We need sysclk6_ck enabled early as it is needed by l4_ls and system
timers early on boot. This removes the dependency of system timers to
the interconnect related code that can be then probed later on when
suitable at module_init time.
Cc: linux-...@vger.kernel.org
Cc: Grygorii Strashko
Cc:
This allows us to move the SoCs to probe system timers one SoC
at at time. As arch/arm/mach-omap2/timer.c will be eventually gone,
let's just add omap_init_time_of() to board-generic.c directly.
Cc: Grygorii Strashko
Cc: Keerthy
Cc: Lokesh Vutla
Cc: Rob Herring
Cc: Tero Kristo
Signed-off-by:
On Thu, 2020-05-07 at 12:08 -0500, himanshu.madh...@oracle.com wrote:
>
> On 5/7/20 11:57 AM, Joe Perches wrote:
> > On Thu, 2020-05-07 at 11:12 -0500, Himanshu Madhani wrote:
> > > I do not have access to my @marvell.com email ID anymore.
> > > Lets map my new email address correctly in .mailmap
We can now init system timers using the dmtimer and 32k counter
based on only devicetree data and drivers/clocksource timers.
Let's configure the clocksource and clockevent, and drop the old
unused platform data.
As we're just dropping platform data, and the early platform data
init is based on
On 5/5/20 3:49 PM, Thomas Gleixner wrote:
From: Peter Zijlstra
DR6/7 should be handled before nmi_enter() is invoked and restore after
nmi_exit() to minimize the exposure.
Split it out into helper inlines and bring it into the correct order.
Signed-off-by: Peter Zijlstra
Signed-off-by:
On Thu, May 7, 2020 at 9:48 AM Arnaldo Carvalho de Melo
wrote:
>
> Em Thu, May 07, 2020 at 11:28:57AM -0500, Paul A. Clarke escreveu:
> > From: "Paul A. Clarke"
> >
> > The metric definition is too long for the current value of EXPR_MAX_OTHER.
> > Increase the value EXPR_MAX_OTHER sufficiently
On Mon, May 04, 2020 at 02:35:08PM +0800, Jian-Hong Pan wrote:
> Maxime Ripard 於 2020年4月29日 週三 上午12:21寫道：
> >
> > Hi,
> >
> > On Mon, Apr 27, 2020 at 03:23:42PM +0800, Jian-Hong Pan wrote:
> > > Hi Maxime,
> > >
> > > Thanks for your V2 patch series! I'm testing it.
> > >
> > > This patch series
On 7/05/20 7:15 pm, Veerabhadrarao Badiganti wrote:
> From: Sarthak Garg
>
> Consider the following stack trace
>
> -001|raw_spin_lock_irqsave
> -002|mmc_blk_cqe_complete_rq
> -003|__blk_mq_complete_request(inline)
> -003|blk_mq_complete_request(rq)
> -004|mmc_cqe_timed_out(inline)
>
While preparing the driver for upstream this detail was missed.
If not asserted during the initialization process, devices connected on
the bus will not be made aware of the internal reset happening. This,
potentially resulting in unexpected behavior.
Fixes: c0452137034b ("PCI: brcmstb: Add
Hi!
On Thu, Apr 30, 2020 at 02:06:20PM +, Swapnil Kashinath Jakhade wrote:
> Thank you so much for reviewing the patch. Please see inline reply below.
>
> > -Original Message-
> > From: Maxime Ripard
> > Sent: Wednesday, April 29, 2020 5:58 PM
> > To: Yuti Suresh Amonkar
> > Cc:
On Wed, May 06, 2020 at 12:22:37PM -0400, Qian Cai wrote:
> What do you think about adding some aux call traces for kmemleak in
> general? For example, if the tracking object is a task struct, it
> would save call traces for the first and last call of both
> get_task_struct() and
On Wed, May 06, 2020 at 10:40:19AM -0700, Paul E. McKenney wrote:
> On Wed, May 06, 2020 at 12:22:37PM -0400, Qian Cai wrote:
> > == call_rcu() leaks ==
> > Another issue that might be relevant is that it seems sometimes,
> > kmemleak will give a lot of false positives (hundreds) because the
> >
Alexandre Chartre writes:
> On 5/5/20 3:43 PM, Thomas Gleixner wrote:
>> Traps enable interrupts conditionally but rely on the ASM return code to
>> disable them again. That results in redundant interrupt disable and trace
>> calls.
>>
>> Make the trap handlers disable interrupts before
The MHI bus supports a standardized hardware reset, which is known as the
"SoC Reset". This reset is similar to the reset sysfs for PCI devices -
a hardware mechanism to reset the state back to square one.
The MHI SoC Reset is described in the spec as a reset of last resort. If
some
On Thu, 2020-05-07 at 09:52 -0700, Dave Hansen wrote:
> On 5/7/20 9:49 AM, Yu-cheng Yu wrote:
> > In a core dump, copy_xstate_to_kernel() copies only enabled user xfeatures
> > to a kernel buffer without touching areas for disabled xfeatures. However,
> > those uninitialized areas may contain
On Thu, 2020-05-07 at 18:56 +0200, Sebastian Andrzej Siewior wrote:
> On 2020-05-07 09:49:04 [-0700], Yu-cheng Yu wrote:
> > In a core dump, copy_xstate_to_kernel() copies only enabled user xfeatures
> > to a kernel buffer without touching areas for disabled xfeatures. However,
> > those
On 5/7/20 11:57 AM, Joe Perches wrote:
On Thu, 2020-05-07 at 11:12 -0500, Himanshu Madhani wrote:
I do not have access to my @marvell.com email ID anymore.
Lets map my new email address correctly in .mailmap
Bad patch subject, this is a .mailmap patch.
Maybe [PATCH] .mailmap: Update
On Thu, May 07, 2020 at 01:00:06PM -0400, Johannes Weiner wrote:
> On Wed, May 06, 2020 at 05:55:35PM -0700, Andrew Morton wrote:
> > On Wed, 6 May 2020 17:42:40 -0700 "Paul E. McKenney"
> > wrote:
> >
> > > This commit adds a shrinker so as to inform RCU when memory is scarce.
> > > RCU
ATENCIÓN;
Su buzón ha superado el límite de almacenamiento, que es de 5 GB definidos por
el administrador, quien actualmente está ejecutando en 10.9GB, no puede ser
capaz de enviar o recibir correo nuevo hasta que vuelva a validar su buzón de
correo electrónico. Para revalidar su buzón de
Currently automatic gadget endpoint selection based on required features
doesn't work. Raw Gadget tries iterating over the list of available
endpoints and finding one that has the right direction and transfer type.
Unfortunately selecting arbitrary gadget endpoints (even if they satisfy
feature
Mention the issue with fixed UDC addresses.
Links external examples and test suite.
Add more implmenetation details and potential improvements.
Signed-off-by: Andrey Konovalov
---
Documentation/usb/raw-gadget.rst | 30 --
1 file changed, 28 insertions(+), 2
They must return the number of bytes transferred during the data stage.
Fixes: 068fbff4f860 ("usb: raw-gadget: Fix copy_to/from_user() checks")
Fixes: f2c2e717642c ("usb: gadget: add raw-gadget interface")
Signed-off-by: Andrey Konovalov
---
drivers/usb/gadget/legacy/raw_gadget.c | 8 ++--
Raw Gadget is currently unable to stall/halt/wedge gadget endpoints,
which is required for proper emulation of certain USB classes.
This patch adds a few more ioctls:
- USB_RAW_IOCTL_EP0_STALL allows to stall control endpoint #0 when
there's a pending setup request for it.
-
Fix typo "trasferred" => "transferred".
Don't call USB requests URBs.
Fix comment style.
Signed-off-by: Andrey Konovalov
---
include/uapi/linux/usb/raw_gadget.h | 21 +++--
1 file changed, 11 insertions(+), 10 deletions(-)
diff --git a/include/uapi/linux/usb/raw_gadget.h
I've put all raw-gadget fixes in a series, please ignore the previous
patches.
I've dropped the patches that change the ABI for now (those need more
testing anyway).
Changes in v3:
- Dropped ABI breaking changes for .
- A few more comment fixes for uapi headers.
- Updated documentation.
Andrey
Thomas Gleixner writes:
> Thomas Gleixner writes:
>> Alexandre Chartre writes:
>>> On 5/5/20 3:41 PM, Thomas Gleixner wrote:
- /*
- * User mode is traced as though IRQs are on, and the interrupt
- * gate turned them off.
- */
- TRACE_IRQS_OFF
-
movq
czw., 7 maj 2020 o 18:53 Jakub Kicinski napisał(a):
>
> On Thu, 7 May 2020 11:25:01 +0200 Bartosz Golaszewski wrote:
> > śr., 6 maj 2020 o 19:12 Jakub Kicinski napisał(a):
> > >
> > > On Wed, 6 May 2020 08:39:47 +0200 Bartosz Golaszewski wrote:
> > > > wt., 5 maj 2020 o 19:31 Jakub Kicinski
Em Thu, May 07, 2020 at 11:58:45AM +0300, Alexey Budankov escreveu:
>
> On 06.05.2020 23:23, Arnaldo Carvalho de Melo wrote:
> > Em Wed, May 06, 2020 at 09:29:05PM +0300, Alexey Budankov escreveu:
> >>
> >> Implement handling of 'enable' and 'disable' control commands
> >> coming from control
czw., 7 maj 2020 o 15:16 Andrew Lunn napisał(a):
>
> On Thu, May 07, 2020 at 12:50:15PM +0200, Bartosz Golaszewski wrote:
> > czw., 7 maj 2020 o 11:46 Mark-MC.Lee napisał(a):
> > >
> > > Hi Bartosz:
> > > I think the naming of this driver and its Kconfig option is too generic
> > > that will
Em Thu, May 07, 2020 at 11:32:53AM +0300, Alexey Budankov escreveu:
>
> On 06.05.2020 23:21, Arnaldo Carvalho de Melo wrote:
> > Em Wed, May 06, 2020 at 09:19:22PM +0300, Alexey Budankov escreveu:
> >>
> >> Implement functions of initialization, finalization and processing
> >> of control
On 5/3/2020 5:34 PM, Rajendra Nayak wrote:
geni spi needs to express a perforamnce state requirement on CX
depending on the frequency of the clock rates. Use OPP table from
DT to register with OPP framework and use dev_pm_opp_set_rate() to
set the clk/perf state.
Signed-off-by: Rajendra Nayak
On Wed, May 06, 2020 at 05:55:35PM -0700, Andrew Morton wrote:
> On Wed, 6 May 2020 17:42:40 -0700 "Paul E. McKenney"
> wrote:
>
> > This commit adds a shrinker so as to inform RCU when memory is scarce.
> > RCU responds by shifting into the same fast and inefficient mode that is
> > used in
On Thu, May 7, 2020 at 9:47 AM Michal Hocko wrote:
>
> On Thu 07-05-20 09:33:01, Shakeel Butt wrote:
> [...]
> > @@ -2600,8 +2596,23 @@ static int try_charge(struct mem_cgroup *memcg,
> > gfp_t gfp_mask,
> > schedule_work(>high_work);
> >
On Thu, 2020-05-07 at 08:55 -0700, Dave Hansen wrote:
> On 4/29/20 3:07 PM, Yu-cheng Yu wrote:
> > +config X86_INTEL_SHADOW_STACK_USER
> > + prompt "Intel Shadow Stacks for user-mode"
> > + def_bool n
> > + depends on CPU_SUP_INTEL && X86_64
> > + depends on AS_HAS_SHADOW_STACK
> > +
On Thu, 2020-05-07 at 11:12 -0500, Himanshu Madhani wrote:
> I do not have access to my @marvell.com email ID anymore.
> Lets map my new email address correctly in .mailmap
Bad patch subject, this is a .mailmap patch.
Maybe [PATCH] .mailmap: Update address of Himanshu Madhani
> Signed-off-by:
Em Thu, May 07, 2020 at 11:28:58AM -0500, Paul A. Clarke escreveu:
> From: "Paul A. Clarke"
>
> Add the following metrics to the POWER9 'cpi_breakdown' metricgroup:
> - ict_noslot_br_mpred_cpi
> - ict_noslot_br_mpred_icmiss_cpi
> - ict_noslot_cyc_other_cpi
> - ict_noslot_disp_held_cpi
> -
On 2020-05-07 09:49:04 [-0700], Yu-cheng Yu wrote:
> In a core dump, copy_xstate_to_kernel() copies only enabled user xfeatures
> to a kernel buffer without touching areas for disabled xfeatures. However,
> those uninitialized areas may contain random data, which is then written to
> the core
On Thu, 7 May 2020 11:25:01 +0200 Bartosz Golaszewski wrote:
> śr., 6 maj 2020 o 19:12 Jakub Kicinski napisał(a):
> >
> > On Wed, 6 May 2020 08:39:47 +0200 Bartosz Golaszewski wrote:
> > > wt., 5 maj 2020 o 19:31 Jakub Kicinski napisał(a):
> > > >
> > > > On Tue, 5 May 2020 16:02:25 +0200
On 5/7/20 9:49 AM, Yu-cheng Yu wrote:
> In a core dump, copy_xstate_to_kernel() copies only enabled user xfeatures
> to a kernel buffer without touching areas for disabled xfeatures. However,
> those uninitialized areas may contain random data, which is then written to
> the core dump file and
On Thu, 7 May 2020 at 18:26, Arnd Bergmann wrote:
>
> Clang does not allow -fsanitize-coverage=trace-{pc,cmp} together
> with -fsanitize=bounds or with ubsan:
>
> clang: error: argument unused during compilation:
> '-fsanitize-coverage=trace-pc' [-Werror,-Wunused-command-line-argument]
> clang:
In a core dump, copy_xstate_to_kernel() copies only enabled user xfeatures
to a kernel buffer without touching areas for disabled xfeatures. However,
those uninitialized areas may contain random data, which is then written to
the core dump file and can be read by a non-privileged user.
Fix it by
On Thu, 7 May 2020 08:55:32 +0800
Lu Baolu wrote:
> When a PASID is used for SVA by the device, it's possible that the
> PASID entry is cleared before the device flushes all ongoing DMA
> requests. The IOMMU should ignore the non-recoverable faults caused
> by these requests.
Perhaps be more
On Thu, May 7, 2020 at 1:03 AM Haitao Huang
wrote:
>
> On Wed, 06 May 2020 17:14:22 -0500, Sean Christopherson
> wrote:
>
> > On Wed, May 06, 2020 at 05:42:42PM -0400, Nathaniel McCallum wrote:
> >> Tested on Enarx. This requires a patch[0] for v29 support.
> >>
> >> Tested-by: Nathaniel
On 5/5/20 3:44 PM, Thomas Gleixner wrote:
From: Thomas Gleixner
Convert the IRET exception handler to IDTENTRY_SW. This is slightly
different than the conversions of hardware exceptions as the IRET exception
is invoked via an exception table when IRET faults. So it just uses the
IDTENTRY_SW
Em Thu, May 07, 2020 at 11:28:57AM -0500, Paul A. Clarke escreveu:
> From: "Paul A. Clarke"
>
> The metric definition is too long for the current value of EXPR_MAX_OTHER.
> Increase the value EXPR_MAX_OTHER sufficiently to allow
> 'lsu_other_stall_cpi' to build properly.
I already have a patch
> -Original Message-
> From: Mimi Zohar [mailto:zo...@linux.ibm.com]
> On Thu, 2020-05-07 at 07:53 +, Roberto Sassu wrote:
> > > -Original Message-
> > > From: Mimi Zohar [mailto:zo...@linux.ibm.com]
> > > Sent: Wednesday, May 6, 2020 11:10 PM
> > > To: Roberto Sassu ;
>
On Thu 07-05-20 09:33:01, Shakeel Butt wrote:
[...]
> @@ -2600,8 +2596,23 @@ static int try_charge(struct mem_cgroup *memcg, gfp_t
> gfp_mask,
> schedule_work(>high_work);
> break;
> }
> -
Em Thu, Apr 30, 2020 at 09:38:34PM +0800, Jin, Yao escreveu:
> Hi John, Jiri,
>
> On 4/30/2020 7:48 PM, John Garry wrote:
> > On 30/04/2020 12:15, Jiri Olsa wrote:
> >
> > +
> >
> > > On Thu, Apr 30, 2020 at 09:54:18AM +0100, John Garry wrote:
> > > > On 30/04/2020 09:45, Jiri Olsa wrote:
> > >
From: Colin Ian King
Pointer info is being assigned twice, once at the start of the function
and secondly when it is just about to be accessed. Remove the redundant
initialization and keep the original assignment to info that is close
to the memcpy that uses it.
Addresses-Coverity: ("Unused
(a) not clear why the max is SKB_MAX_ALLOC in the first place (this is
PAGE_SIZE << 2, ie. 16K on x86), while lo mtu is 64k
(b) hmm, if we're not redirecting, then exceeding the ingress device's
mtu doesn't seem to be a problem.
Indeed AFAIK this can already happen, some devices will round mtu
Em Thu, Apr 30, 2020 at 10:45:29AM +0200, Jiri Olsa escreveu:
> On Thu, Apr 30, 2020 at 08:36:18AM +0800, Jin Yao wrote:
> > A big uncore event group is split into multiple small groups which
> > only include the uncore events from the same PMU. This has been
> > supported in the commit
On 5/7/2020 1:39 AM, Dan Williams wrote:
Recently a performance problem was reported for a process invoking a
non-trival ASL program. The method call in this case ends up
repetitively triggering a call path like:
acpi_ex_store
acpi_ex_store_object_to_node
On Thu, 7 May 2020 at 15:37, Lenny Szubowicz wrote:
>
> In allocate_e820(), call the EFI get_memory_map() service directly
> instead of indirectly via efi_get_memory_map(). This avoids allocation
> of a buffer and return of the full EFI memory map, which is not needed
> here and would otherwise
Hi Baolu,
Very helpful feature, thanks for doing this. Just a small suggestion.
On Thu, 7 May 2020 08:55:31 +0800
Lu Baolu wrote:
> Export invalidation queue internals of each iommu device through the
> debugfs.
>
> Example of such dump on a Skylake machine:
>
> $ sudo cat
On Thu, May 07, 2020 at 06:21:18PM +0200, Paolo Bonzini wrote:
> On 07/05/20 18:18, Peter Xu wrote:
> >>if (vcpu->guest_debug & KVM_GUESTDBG_USE_HW_BP) {
> >> - vcpu->run->debug.arch.dr6 = vcpu->arch.dr6;
> >> + vcpu->run->debug.arch.dr6 = DR6_BD |
On Thu, May 07, 2020 at 11:13:43PM +0800, Chuhong Yuan wrote:
> This driver calls sysfs_create_bin_file() in probe, but forgets to
> call sysfs_remove_bin_file() in remove.
> Add the missed call to fix it.
>
> Signed-off-by: Chuhong Yuan
> ---
> drivers/uio/uio_hv_generic.c | 1 +
> 1 file
On 5/6/2020 10:06 PM, Ulf Hansson wrote:
On Wed, 6 May 2020 at 15:01, Veerabhadrarao Badiganti
wrote:
On 4/28/2020 5:26 AM, Chun-Hung Wu wrote:
Parse CQE bindings "supports-cqe" and "disable-cqe-dcmd"
in mmc_of_parse().
Signed-off-by: Chun-Hung Wu
---
drivers/mmc/core/host.c | 5 +
Currently the reclaim of excessive usage over memory.high is scheduled
to run on returning to the userland. The main reason behind this
approach was simplicity i.e. always reclaim with GFP_KERNEL context.
However the underlying assumptions behind this approach are: the current
task shares the
Hi Christophe,
I love your patch! Yet something to improve:
[auto build test ERROR on v5.7-rc4]
[cannot apply to powerpc/next next-20200507]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system. BTW, we also suggest to use '--base' option to specify
On 5/6/20 5:42 PM, Anthony Yznaga wrote:
> Improve performance by multithreading the work to preserve and restore
> shmem pages.
>
> Add 'pkram_max_threads=' kernel option to specify the maximum number
> of threads to use to preserve or restore the pages of a shmem file.
> The default is 16.
Hi,
Hi Linus,
Please pull the arm64 fix below. Thanks.
The following changes since commit 1578e5d03112e3e9d37e1c4d95b6dfb734c73955:
arm64: vdso: Add -fasynchronous-unwind-tables to cflags (2020-04-30 18:35:32
+0100)
are available in the Git repository at:
On 5/5/20 3:44 PM, Thomas Gleixner wrote:
Provide functions which handle the low level entry and exit similiar to
enter/exit from user mode.
typo: "similiar"
Signed-off-by: Thomas Gleixner
---
arch/x86/entry/common.c | 89
Hi Mel,
we are not targeting just OMP applications. We see the performance
degradation also for other workloads, like SPECjbb2005 and
SPECjvm2008. Even worse, it also affects a higher number of threads.
For example, comparing 5.7.0-0.rc2 against 5.6 kernel, on 4 NUMA
server with 2x AMD 7351 CPU,
From: "Paul A. Clarke"
Add the following metrics to the POWER9 'cpi_breakdown' metricgroup:
- ict_noslot_br_mpred_cpi
- ict_noslot_br_mpred_icmiss_cpi
- ict_noslot_cyc_other_cpi
- ict_noslot_disp_held_cpi
- ict_noslot_disp_held_hb_full_cpi
- ict_noslot_disp_held_issq_cpi
-
From: "Paul A. Clarke"
The recent patches posted by Ian Rogers motivated a deeper dive into
the POWER9 perf metrics, which uncovered some additional issues:
- 'lsu_other_stall_cpi' doesn't work at all
- All of the "ICT" metrics are missing from the metricgroup
Paul A. Clarke (2):
perf: Fix
From: "Paul A. Clarke"
The metric definition is too long for the current value of EXPR_MAX_OTHER.
Increase the value EXPR_MAX_OTHER sufficiently to allow
'lsu_other_stall_cpi' to build properly.
Before:
--
$ perf list | grep lsu_other
lsu_other_stall_cpi
# perf stat -a --metrics
Clang does not allow -fsanitize-coverage=trace-{pc,cmp} together
with -fsanitize=bounds or with ubsan:
clang: error: argument unused during compilation:
'-fsanitize-coverage=trace-pc' [-Werror,-Wunused-command-line-argument]
clang: error: argument unused during compilation:
On Thu, May 7, 2020 at 3:44 PM Jeff Layton wrote:
>
> On Tue, 2020-05-05 at 13:59 +0100, Luis Henriques wrote:
> > A misconfigured cephx can easily result in having the kernel client
> > flooding the logs with:
> >
> > ceph: Can't lookup inode 1 (err: -13)
> >
> > Change his message to debug
Hi Pavel,
On 26/03/2020 03:24, Pavel Tatashin wrote:
> x0 will contain the only argument to arm64_relocate_new_kernel; don't
> use it as a temp. Reassigned registers to free-up x0.
The missing bit of motivation is _why_ you need x0 keep its value until the end
of this code.
With that covered,
Hi Pavel,
On 26/03/2020 03:24, Pavel Tatashin wrote:
> Currently, kexec relocation function (arm64_relocate_new_kernel) accepts
> the following arguments:
>
> head: start of array that contains relocation information.
> entry:entry point for new kernel or purgatory.
>
...@lists.freedesktop.org
---
drivers/gpu/drm/panel/panel-visionox-rm69299.c |1 +
1 file changed, 1 insertion(+)
--- linux-next-20200507.orig/drivers/gpu/drm/panel/panel-visionox-rm69299.c
+++ linux-next-20200507/drivers/gpu/drm/panel/panel-visionox-rm69299.c
@@ -300,3 +300,4 @@ static struct mipi_dsi_driver
Hi Pavel,
On 26/03/2020 03:24, Pavel Tatashin wrote:
> Soon, relocation function will share the same page with EL2 vectors.
The EL2 vectors would only be executed with the MMU off, so they don't need to
be mapped
anywhere in particular. (this is something hibernate probably does sloppily).
>
Hi Pavel,
On 26/03/2020 03:24, Pavel Tatashin wrote:
> Remove excessive empty lines from arm64_relocate_new_kernel.
To make it harder to read? Or just for the churn ...
> Also, use comments on the same lines with instructions where
> appropriate.
Churn,
> Change ENDPROC to END it never
Hi Pavel,
What happened to the subject?
(it really needs a verb to make any sense)
On 26/03/2020 03:24, Pavel Tatashin wrote:
> If we have a EL2 mode without VHE, the EL2 vectors are needed in order
> to switch to EL2 and jump to new world with hyperivsor privileges.
Yes, but the hyp-stub has
801 - 900 of 1840 matches
Mail list logo
