RE: [Intel-wired-lan] e1000e: PHY cann't be initialized correctly on some I218 controllers

> -Original Message- > From: Avargil, Raanan > Sent: Tuesday, August 9, 2016 8:11 AM > To: Denis Turischev ; intel-wired- > l...@lists.osuosl.org; Brown, Aaron F ; Kirsher, > Jeffrey T > Cc:

RE: [Intel-wired-lan] e1000e: PHY cann't be initialized correctly on some I218 controllers

> -Original Message- > From: Avargil, Raanan > Sent: Tuesday, August 9, 2016 8:11 AM > To: Denis Turischev ; intel-wired- > l...@lists.osuosl.org; Brown, Aaron F ; Kirsher, > Jeffrey T > Cc: net...@vger.kernel.org; linux-kernel@vger.kernel.org > Subject: Re: [Intel-wired-lan] e1000e:

Re: [PATCH] max17042_battery: fix model download bug.

Hi, [adding some people to CC] On Wed, Aug 03, 2016 at 10:03:46AM -0400, Sven Van Asbroeck wrote: > The device's model download function returns the model data as > an array of u32s, which is later compared to the reference > model data. However, since the latter is an array of u16s, > the

Re: [PATCH] max17042_battery: fix model download bug.

Hi, [adding some people to CC] On Wed, Aug 03, 2016 at 10:03:46AM -0400, Sven Van Asbroeck wrote: > The device's model download function returns the model data as > an array of u32s, which is later compared to the reference > model data. However, since the latter is an array of u16s, > the

Re: [PATCH v4] ARM: pxa: fix GPIO double shifts

Robert Jarzmik writes: > The commit 9bf448c66d4b ("ARM: pxa: use generic gpio operation instead of > gpio register") from Oct 17, 2011, leads to the following static checker > warning: > arch/arm/mach-pxa/spitz_pm.c:172 spitz_charger_wakeup() > warn: double left shift

spin_lock implicit/explicit memory barrier

Hi Benjamin, Hi Michael, regarding commit 51d7d5205d33 ("powerpc: Add smp_mb() to arch_spin_is_locked()"): For the ipc/sem code, I would like to replace the spin_is_locked() with a smp_load_acquire(), see: http://git.cmpxchg.org/cgit.cgi/linux-mmots.git/tree/ipc/sem.c#n367

Re: [PATCH v4] ARM: pxa: fix GPIO double shifts

Robert Jarzmik writes: > The commit 9bf448c66d4b ("ARM: pxa: use generic gpio operation instead of > gpio register") from Oct 17, 2011, leads to the following static checker > warning: > arch/arm/mach-pxa/spitz_pm.c:172 spitz_charger_wakeup() > warn: double left shift

spin_lock implicit/explicit memory barrier

Hi Benjamin, Hi Michael, regarding commit 51d7d5205d33 ("powerpc: Add smp_mb() to arch_spin_is_locked()"): For the ipc/sem code, I would like to replace the spin_is_locked() with a smp_load_acquire(), see: http://git.cmpxchg.org/cgit.cgi/linux-mmots.git/tree/ipc/sem.c#n367

Re: [PATCH 5/5] arm64: Add uprobe support

On 08/02, Pratyush Anand wrote: > > This patch adds support for uprobe on ARM64 architecture. I know nothing about ARM, so I can't actually review this change. But it looks good to me ;) Just one note, > +int arch_uprobe_pre_xol(struct arch_uprobe *auprobe, struct pt_regs *regs) > +{ > +

Re: [PATCH 5/5] arm64: Add uprobe support

On 08/02, Pratyush Anand wrote: > > This patch adds support for uprobe on ARM64 architecture. I know nothing about ARM, so I can't actually review this change. But it looks good to me ;) Just one note, > +int arch_uprobe_pre_xol(struct arch_uprobe *auprobe, struct pt_regs *regs) > +{ > +

Re: [PATCH] sched: Avoid that __wait_on_bit_lock() hangs

On 08/09/2016 10:15 AM, Oleg Nesterov wrote: > On 08/08, Bart Van Assche wrote: >> >> No external modules were loaded when I triggered the lockup > > Heh. Could you test the patch below? > > Oleg. > > --- x/kernel/sched/wait.c > +++ x/kernel/sched/wait.c > @@ -283,7 +283,7 @@ void

Re: [PATCH] sched: Avoid that __wait_on_bit_lock() hangs

On 08/09/2016 10:15 AM, Oleg Nesterov wrote: > On 08/08, Bart Van Assche wrote: >> >> No external modules were loaded when I triggered the lockup > > Heh. Could you test the patch below? > > Oleg. > > --- x/kernel/sched/wait.c > +++ x/kernel/sched/wait.c > @@ -283,7 +283,7 @@ void

Re: [PATCH v2 3/3] powerpc: Convert fsl_rstcr_restart to a reset handler

On Sun, Jul 31, 2016 at 9:03 PM, Nicholas Piggin wrote: > On Thu, 28 Jul 2016 16:07:18 -0700 > Andrey Smirnov wrote: > >> Convert fsl_rstcr_restart into a function to be registered with >> register_reset_handler(). >> >> Signed-off-by: Andrey Smirnov

Re: [PATCH v2 3/3] powerpc: Convert fsl_rstcr_restart to a reset handler

On Sun, Jul 31, 2016 at 9:03 PM, Nicholas Piggin wrote: > On Thu, 28 Jul 2016 16:07:18 -0700 > Andrey Smirnov wrote: > >> Convert fsl_rstcr_restart into a function to be registered with >> register_reset_handler(). >> >> Signed-off-by: Andrey Smirnov >> --- >> >> Changes since v1: >> >> -

Re: c6x linker issue on linux-next-20160808 + some linker table work

On Tue, 2016-08-09 at 20:40 +0200, Luis R. Rodriguez wrote: > On Tue, Aug 09, 2016 at 01:04:00PM -0400, Mark Salter wrote: > > > > On Tue, 2016-08-09 at 06:37 -0700, Guenter Roeck wrote: > > > > > > On 08/09/2016 01:11 AM, Luis R. Rodriguez wrote: > > > > > > > > > > > > Mark, Aurelien, > > >

Re: c6x linker issue on linux-next-20160808 + some linker table work

On Tue, 2016-08-09 at 20:40 +0200, Luis R. Rodriguez wrote: > On Tue, Aug 09, 2016 at 01:04:00PM -0400, Mark Salter wrote: > > > > On Tue, 2016-08-09 at 06:37 -0700, Guenter Roeck wrote: > > > > > > On 08/09/2016 01:11 AM, Luis R. Rodriguez wrote: > > > > > > > > > > > > Mark, Aurelien, > > >

Re: [PATCH v5 5/5] lib/dlock-list: Make sibling CPUs share the same linked list

Hi Waiman, [auto build test ERROR on linus/master] [also build test ERROR on v4.8-rc1 next-20160809] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Waiman-Long/vfs-Use-dlock-list-for-SB-s

Re: [PATCH v5 5/5] lib/dlock-list: Make sibling CPUs share the same linked list

Hi Waiman, [auto build test ERROR on linus/master] [also build test ERROR on v4.8-rc1 next-20160809] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Waiman-Long/vfs-Use-dlock-list-for-SB-s

Re: mwifiex: PCIe8997 chip specific handling

Hi, On Fri, Jul 29, 2016 at 04:08:51PM +0530, Amitkumar Karwar wrote: > The patch corrects the revision id register and uses it along with > magic value and chip version registers to download appropriate firmware > image. > > PCIe8997 Z chipset variant code has been removed, as it won't be used

Re: mwifiex: PCIe8997 chip specific handling

Hi, On Fri, Jul 29, 2016 at 04:08:51PM +0530, Amitkumar Karwar wrote: > The patch corrects the revision id register and uses it along with > magic value and chip version registers to download appropriate firmware > image. > > PCIe8997 Z chipset variant code has been removed, as it won't be used

Re: [PATCH] x86/mm: minor warning message cleanup

On Tue, Aug 09, 2016 at 01:56:31PM -0400, Prarit Bhargava wrote: > Capitalize R in RIP. > > Signed-off-by: Prarit Bhargava > Cc: Thomas Gleixner > Cc: Ingo Molnar > Cc: "H. Peter Anvin" > Cc: x...@kernel.org > Cc: Andy

Re: [PATCH] x86/mm: minor warning message cleanup

On Tue, Aug 09, 2016 at 01:56:31PM -0400, Prarit Bhargava wrote: > Capitalize R in RIP. > > Signed-off-by: Prarit Bhargava > Cc: Thomas Gleixner > Cc: Ingo Molnar > Cc: "H. Peter Anvin" > Cc: x...@kernel.org > Cc: Andy Lutomirski > Cc: Borislav Petkov > Cc: Andrew Morton > Cc: Ard

Re: c6x linker issue on linux-next-20160808 + some linker table work

On Tue, Aug 09, 2016 at 01:04:00PM -0400, Mark Salter wrote: > On Tue, 2016-08-09 at 06:37 -0700, Guenter Roeck wrote: > > On 08/09/2016 01:11 AM, Luis R. Rodriguez wrote: > > > > > > Mark, Aurelien, > > > > > > I've run into a linker (ld) issue caused by the linker table work I've > > > been

Re: c6x linker issue on linux-next-20160808 + some linker table work

On Tue, Aug 09, 2016 at 01:04:00PM -0400, Mark Salter wrote: > On Tue, 2016-08-09 at 06:37 -0700, Guenter Roeck wrote: > > On 08/09/2016 01:11 AM, Luis R. Rodriguez wrote: > > > > > > Mark, Aurelien, > > > > > > I've run into a linker (ld) issue caused by the linker table work I've > > > been

Re: [RFC][PATCH 5/3] tracing: Add smi counting to HWLAT

On Tue, 9 Aug 2016 15:28:57 -0300 Daniel Bristot de Oliveira wrote: > On 08/09/2016 03:05 PM, Steven Rostedt wrote: > > If an arch supports counting of SMIs (like newer intel chips do), then it > > can implement arch_smi_count() to return the number of SMIs that were > >

Re: [RFC][PATCH 5/3] tracing: Add smi counting to HWLAT

On Tue, 9 Aug 2016 15:28:57 -0300 Daniel Bristot de Oliveira wrote: > On 08/09/2016 03:05 PM, Steven Rostedt wrote: > > If an arch supports counting of SMIs (like newer intel chips do), then it > > can implement arch_smi_count() to return the number of SMIs that were > > triggered. The hwlat

Re: [PATCH v4 3/3] locking/mutex: Ensure forward progress of waiter-spinner

On 08/08/2016 01:37 PM, Peter Zijlstra wrote: On Mon, Jul 18, 2016 at 04:39:26PM -0400, Waiman Long wrote: As both an optimistic spinner and a waiter-spinner (a woken task from the wait queue spinning) can be spinning on the lock at the same time, we cannot ensure forward progress for the

Re: [PATCH v4 3/3] locking/mutex: Ensure forward progress of waiter-spinner

On 08/08/2016 01:37 PM, Peter Zijlstra wrote: On Mon, Jul 18, 2016 at 04:39:26PM -0400, Waiman Long wrote: As both an optimistic spinner and a waiter-spinner (a woken task from the wait queue spinning) can be spinning on the lock at the same time, we cannot ensure forward progress for the

Re: [PATCH 0/5] ipc/msg: Sender/receiver optimizations

On Tue, 9 Aug 2016 14:44:26 +0200 Peter Zijlstra wrote: > On Thu, Aug 04, 2016 at 06:44:09PM +0200, Peter Zijlstra wrote: > > On Thu, Jul 28, 2016 at 04:33:34PM -0700, Davidlohr Bueso wrote: > > > Hi, > > > > > > I'm resending Sebastian's sysv msg queue use of wake_qs but

Re: [PATCH 0/5] ipc/msg: Sender/receiver optimizations

On Tue, 9 Aug 2016 14:44:26 +0200 Peter Zijlstra wrote: > On Thu, Aug 04, 2016 at 06:44:09PM +0200, Peter Zijlstra wrote: > > On Thu, Jul 28, 2016 at 04:33:34PM -0700, Davidlohr Bueso wrote: > > > Hi, > > > > > > I'm resending Sebastian's sysv msg queue use of wake_qs but updated > > > to the

drivers/gpu/drm/udl/udl_fb.c:214: error: dereferencing pointer to incomplete type

tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: 81abf2525827b29839a78fd55ab0699f033c41a5 commit: 0b6320dfdfea4c68602fa3b8a8d944bf9e442079 drm/virtio: make fbdev support really optional date: 3 weeks ago config: x86_64-randconfig-a0-08100141 (attached

drivers/gpu/drm/udl/udl_fb.c:214: error: dereferencing pointer to incomplete type

tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: 81abf2525827b29839a78fd55ab0699f033c41a5 commit: 0b6320dfdfea4c68602fa3b8a8d944bf9e442079 drm/virtio: make fbdev support really optional date: 3 weeks ago config: x86_64-randconfig-a0-08100141 (attached

Re: [RFC][PATCH 0/3] tracing: Add Hardware Latency detector tracer

On Tue, 9 Aug 2016 13:15:16 -0500 Clark Williams wrote: > On Thu, 4 Aug 2016 11:30:33 -0400 > Steven Rostedt wrote: > > > Note, I'm currently working on adding code to detect NMIs to this as > > well. And perhaps even tracing SMI counters. Just to show

Re: [RFC][PATCH 0/3] tracing: Add Hardware Latency detector tracer

On Tue, 9 Aug 2016 13:15:16 -0500 Clark Williams wrote: > On Thu, 4 Aug 2016 11:30:33 -0400 > Steven Rostedt wrote: > > > Note, I'm currently working on adding code to detect NMIs to this as > > well. And perhaps even tracing SMI counters. Just to show what caused > > the latency, as latency

Re: [RFC][PATCH 5/3] tracing: Add smi counting to HWLAT

On 08/09/2016 03:05 PM, Steven Rostedt wrote: > If an arch supports counting of SMIs (like newer intel chips do), then it > can implement arch_smi_count() to return the number of SMIs that were > triggered. The hwlat detector will call this function to get the current > number of SMIs, and then

Re: [RFC][PATCH 5/3] tracing: Add smi counting to HWLAT

On 08/09/2016 03:05 PM, Steven Rostedt wrote: > If an arch supports counting of SMIs (like newer intel chips do), then it > can implement arch_smi_count() to return the number of SMIs that were > triggered. The hwlat detector will call this function to get the current > number of SMIs, and then

Re: [PACTH v1] mm, proc: Implement /proc//totmaps

On Tue, Aug 9, 2016 at 9:58 AM, Alexey Dobriyan wrote: > > On Tue, Aug 09, 2016 at 12:05:43PM -0400, robert.f...@collabora.com wrote: > > From: Sonny Rao > > > > This is based on earlier work by Thiago Goncales. It implements a new > > per process proc

Re: [PACTH v1] mm, proc: Implement /proc//totmaps

On Tue, Aug 9, 2016 at 9:58 AM, Alexey Dobriyan wrote: > > On Tue, Aug 09, 2016 at 12:05:43PM -0400, robert.f...@collabora.com wrote: > > From: Sonny Rao > > > > This is based on earlier work by Thiago Goncales. It implements a new > > per process proc file which summarizes the contents of the

Re: [PATCH v2 2/3] powerpc: Call chained reset handlers during reset

On Sun, Jul 31, 2016 at 8:47 PM, Nicholas Piggin wrote: > On Thu, 28 Jul 2016 16:07:17 -0700 > Andrey Smirnov wrote: > >> Call out to all restart handlers that were added via >> register_restart_handler() API when restarting the machine. >> >>

Re: [PATCH v2 2/3] powerpc: Call chained reset handlers during reset

On Sun, Jul 31, 2016 at 8:47 PM, Nicholas Piggin wrote: > On Thu, 28 Jul 2016 16:07:17 -0700 > Andrey Smirnov wrote: > >> Call out to all restart handlers that were added via >> register_restart_handler() API when restarting the machine. >> >> Signed-off-by: Andrey Smirnov >> --- >> >> No

Re: [PATCH v2] exynos-drm: Fix unsupported GEM memory type error message to be clear

On Mon, Aug 08, 2016 at 05:48:20PM -0600, Shuah Khan wrote: > Fix unsupported GEM memory type error message to include the memory type > information. > > Signed-off-by: Shuah Khan > --- > Changes since v1: > -- Comment changed to read clearly > >

Re: [PATCH v2] exynos-drm: Fix unsupported GEM memory type error message to be clear

On Mon, Aug 08, 2016 at 05:48:20PM -0600, Shuah Khan wrote: > Fix unsupported GEM memory type error message to include the memory type > information. > > Signed-off-by: Shuah Khan > --- > Changes since v1: > -- Comment changed to read clearly > > drivers/gpu/drm/exynos/exynos_drm_fb.c | 6

Re: [PATCH] hwrng: core - Allow for multiple simultaneous active hwrng devices

Hi Keith, On Tue, Aug 09, 2016 at 10:58:05AM -0700, Keith Packard wrote: > Jason Cooper writes: > > Perhaps a /dev/hwrng[0-9] per rng? That would lend itself nicely to a > > sysfs interface for per device quality, rate, and enabled attributes. > > e.g.

Re: [PATCH] hwrng: core - Allow for multiple simultaneous active hwrng devices

Hi Keith, On Tue, Aug 09, 2016 at 10:58:05AM -0700, Keith Packard wrote: > Jason Cooper writes: > > Perhaps a /dev/hwrng[0-9] per rng? That would lend itself nicely to a > > sysfs interface for per device quality, rate, and enabled attributes. > > e.g.

Re: [PATCH v5 5/5] lib/dlock-list: Make sibling CPUs share the same linked list

Hi Waiman, [auto build test ERROR on linus/master] [also build test ERROR on v4.8-rc1 next-20160809] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Waiman-Long/vfs-Use-dlock-list-for-SB-s

Re: [PATCH v5 5/5] lib/dlock-list: Make sibling CPUs share the same linked list

Hi Waiman, [auto build test ERROR on linus/master] [also build test ERROR on v4.8-rc1 next-20160809] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Waiman-Long/vfs-Use-dlock-list-for-SB-s

Re: [PATCH v7 4/4] nmi_backtrace: generate one-line reports for idle cpus

On 8/9/2016 8:43 AM, Petr Mladek wrote: On Mon 2016-08-08 12:03:38, Chris Metcalf wrote: When doing an nmi backtrace of many cores, most of which are idle, the output is a little overwhelming and very uninformative. Suppress messages for cpus that are idling when they are interrupted and just

Re: [PATCH v7 4/4] nmi_backtrace: generate one-line reports for idle cpus

On 8/9/2016 8:43 AM, Petr Mladek wrote: On Mon 2016-08-08 12:03:38, Chris Metcalf wrote: When doing an nmi backtrace of many cores, most of which are idle, the output is a little overwhelming and very uninformative. Suppress messages for cpus that are idling when they are interrupted and just

Re: [RFC][PATCH 0/3] tracing: Add Hardware Latency detector tracer

On Thu, 4 Aug 2016 11:30:33 -0400 Steven Rostedt wrote: > Note, I'm currently working on adding code to detect NMIs to this as > well. And perhaps even tracing SMI counters. Just to show what caused > the latency, as latency isn't measured by the counters (that I know of). >

Re: [RFC][PATCH 0/3] tracing: Add Hardware Latency detector tracer

On Thu, 4 Aug 2016 11:30:33 -0400 Steven Rostedt wrote: > Note, I'm currently working on adding code to detect NMIs to this as > well. And perhaps even tracing SMI counters. Just to show what caused > the latency, as latency isn't measured by the counters (that I know of). > I like the trace

Re: [PATCHv2 3/4] pci: Determine actual VPD size on first access

On Tue, Aug 9, 2016 at 5:54 AM, Alexey Kardashevskiy wrote: > On 10/02/16 08:04, Bjorn Helgaas wrote: >> On Wed, Jan 13, 2016 at 12:25:34PM +0100, Hannes Reinecke wrote: >>> PCI-2.2 VPD entries have a maximum size of 32k, but might actually >>> be smaller than that. To figure out

Re: [PATCHv2 3/4] pci: Determine actual VPD size on first access

On Tue, Aug 9, 2016 at 5:54 AM, Alexey Kardashevskiy wrote: > On 10/02/16 08:04, Bjorn Helgaas wrote: >> On Wed, Jan 13, 2016 at 12:25:34PM +0100, Hannes Reinecke wrote: >>> PCI-2.2 VPD entries have a maximum size of 32k, but might actually >>> be smaller than that. To figure out the actual size

Re: [PATCH v9 0/9] acpi, clocksource: add GTDT driver and GTDT support in arm_arch_timer

Hi Tomasz On 9 August 2016 at 19:03, Tomasz Nowicki wrote: > Hi Fu, > > Are you planing to respin the series based on v4.8-rc1 ? My IORT patches > depend on this series since they will end up in the same drivers/acpi/arm64/ > > I think patches are in good shape so we need to

Re: [PATCH v9 0/9] acpi, clocksource: add GTDT driver and GTDT support in arm_arch_timer

Hi Tomasz On 9 August 2016 at 19:03, Tomasz Nowicki wrote: > Hi Fu, > > Are you planing to respin the series based on v4.8-rc1 ? My IORT patches > depend on this series since they will end up in the same drivers/acpi/arm64/ > > I think patches are in good shape so we need to enquire who is going

Re: [PATCH 1/9] remoteproc: core: Ensure error message is clear

On Tue, 09 Aug 2016, Bjorn Andersson wrote: > On Thu 04 Aug 02:21 PDT 2016, Lee Jones wrote: > > > Before this patch, the dma_alloc_coherent() failure path printed out: > > > > "dma_alloc_coherent err: 16760832" > > > > ... alluding to the Linux error code being 16760832, but seeing as > >

Re: [PATCH 1/9] remoteproc: core: Ensure error message is clear

On Tue, 09 Aug 2016, Bjorn Andersson wrote: > On Thu 04 Aug 02:21 PDT 2016, Lee Jones wrote: > > > Before this patch, the dma_alloc_coherent() failure path printed out: > > > > "dma_alloc_coherent err: 16760832" > > > > ... alluding to the Linux error code being 16760832, but seeing as > >

Re: [PATCH 2/9] remoteproc: core: Trivial: Improve error checking, spelling and debug prints

On Tue, 09 Aug 2016, Bjorn Andersson wrote: > On Thu 04 Aug 02:21 PDT 2016, Lee Jones wrote: > > > Trivial patch to clean up a couple of minor misgivings. > > > > Signed-off-by: Lee Jones > > Acked-by: Bjorn Andersson You can just take it.

Re: [PATCH 2/9] remoteproc: core: Trivial: Improve error checking, spelling and debug prints

On Tue, 09 Aug 2016, Bjorn Andersson wrote: > On Thu 04 Aug 02:21 PDT 2016, Lee Jones wrote: > > > Trivial patch to clean up a couple of minor misgivings. > > > > Signed-off-by: Lee Jones > > Acked-by: Bjorn Andersson You can just take it. > Although as I hope to stack this series ontop of

Re: [PATCH 3/9] remoteproc: core: Remove pointless OOM print

On Tue, 09 Aug 2016, Bjorn Andersson wrote: > On Thu 04 Aug 02:21 PDT 2016, Lee Jones wrote: > > > These types of error prints are superfluous. The system will > > pick up on OOM issues and let the user know. > > > > Signed-off-by: Lee Jones > > Acked-by: Bjorn

Re: [PATCH 3/9] remoteproc: core: Remove pointless OOM print

On Tue, 09 Aug 2016, Bjorn Andersson wrote: > On Thu 04 Aug 02:21 PDT 2016, Lee Jones wrote: > > > These types of error prints are superfluous. The system will > > pick up on OOM issues and let the user know. > > > > Signed-off-by: Lee Jones > > Acked-by: Bjorn Andersson This doesn't rely

[RFC][PATCH 5/3] tracing: Add smi counting to HWLAT

If an arch supports counting of SMIs (like newer intel chips do), then it can implement arch_smi_count() to return the number of SMIs that were triggered. The hwlat detector will call this function to get the current number of SMIs, and then after a period, it will read that function again, and

[RFC][PATCH 5/3] tracing: Add smi counting to HWLAT

If an arch supports counting of SMIs (like newer intel chips do), then it can implement arch_smi_count() to return the number of SMIs that were triggered. The hwlat detector will call this function to get the current number of SMIs, and then after a period, it will read that function again, and

[v2 PATCH] clk: rockchip: mark rk3399 hdcp_noc and vio_noc as critical

Fix incorrect rk3399 aclk_vio gating bit, it should be 0, not 10. With this modification, the aclk_vio_noc should be put into critical list, since it is required by VOP. And the Type-C DP need these clocks: aclk_hdcp_noc, hclk_hdcp_noc, pclk_hdcp_noc. Mark them as critical to avoid someone close

[v2 PATCH] clk: rockchip: mark rk3399 hdcp_noc and vio_noc as critical

Fix incorrect rk3399 aclk_vio gating bit, it should be 0, not 10. With this modification, the aclk_vio_noc should be put into critical list, since it is required by VOP. And the Type-C DP need these clocks: aclk_hdcp_noc, hclk_hdcp_noc, pclk_hdcp_noc. Mark them as critical to avoid someone close

Re: [PATCH v7 4/4] nmi_backtrace: generate one-line reports for idle cpus

On 8/9/2016 6:37 AM, Lorenzo Pieralisi wrote: On Mon, Aug 08, 2016 at 05:48:28PM +0100, Mark Rutland wrote: Hi, [adding Lorenzo] On Mon, Aug 08, 2016 at 12:03:38PM -0400, Chris Metcalf wrote: When doing an nmi backtrace of many cores, most of which are idle, the output is a little

Re: [PATCH v7 4/4] nmi_backtrace: generate one-line reports for idle cpus

On 8/9/2016 6:37 AM, Lorenzo Pieralisi wrote: On Mon, Aug 08, 2016 at 05:48:28PM +0100, Mark Rutland wrote: Hi, [adding Lorenzo] On Mon, Aug 08, 2016 at 12:03:38PM -0400, Chris Metcalf wrote: When doing an nmi backtrace of many cores, most of which are idle, the output is a little

Re: [PATCH] hwrng: core - Allow for multiple simultaneous active hwrng devices

Jason Cooper writes: > Perhaps a /dev/hwrng[0-9] per rng? That would lend itself nicely to a > sysfs interface for per device quality, rate, and enabled attributes. > e.g. /sys/class/hw_random/hwrng0/{device/,quality,rate,enabled} I was interested in the data being

Re: [PATCH] hwrng: core - Allow for multiple simultaneous active hwrng devices

Jason Cooper writes: > Perhaps a /dev/hwrng[0-9] per rng? That would lend itself nicely to a > sysfs interface for per device quality, rate, and enabled attributes. > e.g. /sys/class/hw_random/hwrng0/{device/,quality,rate,enabled} I was interested in the data being provided for /dev/random;

[PATCH] x86/mm: minor warning message cleanup

Capitalize R in RIP. Signed-off-by: Prarit Bhargava Cc: Thomas Gleixner Cc: Ingo Molnar Cc: "H. Peter Anvin" Cc: x...@kernel.org Cc: Andy Lutomirski Cc: Borislav Petkov Cc: Andrew Morton

[PATCH] x86/mm: minor warning message cleanup

Capitalize R in RIP. Signed-off-by: Prarit Bhargava Cc: Thomas Gleixner Cc: Ingo Molnar Cc: "H. Peter Anvin" Cc: x...@kernel.org Cc: Andy Lutomirski Cc: Borislav Petkov Cc: Andrew Morton Cc: Ard Biesheuvel Cc: Tony Luck --- arch/x86/mm/extable.c |2 +- 1 file changed, 1

RE: [PATCH] megaraid_sas: Fix probing cards without io port

> > that does not io port resource allocated from BIOS, and kernel can not > > assign one as io port shortage. > > > > The driver is only looking for MEM, and should not fail. > > > It turns out megasas_init_fw() etc are using bar index as mask. > > index 1 is used as mask 1, so that

RE: [PATCH] megaraid_sas: Fix probing cards without io port

> > that does not io port resource allocated from BIOS, and kernel can not > > assign one as io port shortage. > > > > The driver is only looking for MEM, and should not fail. > > > It turns out megasas_init_fw() etc are using bar index as mask. > > index 1 is used as mask 1, so that

Re: [PATCH v4 2/3] locking/mutex: Enable optimistic spinning of woken task in wait queue

On 08/08/2016 01:29 PM, Peter Zijlstra wrote: On Mon, Jul 18, 2016 at 04:39:25PM -0400, Waiman Long wrote: Ding Tianhong reported a live-lock situation where a constant stream of incoming optimistic spinners blocked a task in the wait list from getting the mutex. This patch attempts to fix

Re: [PATCH v4 2/3] locking/mutex: Enable optimistic spinning of woken task in wait queue

On 08/08/2016 01:29 PM, Peter Zijlstra wrote: On Mon, Jul 18, 2016 at 04:39:25PM -0400, Waiman Long wrote: Ding Tianhong reported a live-lock situation where a constant stream of incoming optimistic spinners blocked a task in the wait list from getting the mutex. This patch attempts to fix

Re: [PATCH v2] net: dsa: b53: constify b53_io_ops structures

On 08/09/2016 10:09 AM, Julia Lawall wrote: > The b53_io_ops structures are never modified, so declare them as const. > > Done with the help of Coccinelle. > > Signed-off-by: Julia Lawall Acked-by: Florian Fainelli -- Florian

Re: [PATCH v2] net: dsa: b53: constify b53_io_ops structures

On 08/09/2016 10:09 AM, Julia Lawall wrote: > The b53_io_ops structures are never modified, so declare them as const. > > Done with the help of Coccinelle. > > Signed-off-by: Julia Lawall Acked-by: Florian Fainelli -- Florian

Re: [PATCH 8/9] remoteproc: core: Skip resource table integrity checks if there are amendments

On Thu 04 Aug 02:21 PDT 2016, Lee Jones wrote: > There is little point wasting CPU cycles completing integrity checking > (i.e. ensuring nothing has changed) on the resource table if we *know* > that it will be changed (by us). In this patch we skip resource table > integrity checks if a

Re: [PATCH 8/9] remoteproc: core: Skip resource table integrity checks if there are amendments

On Thu 04 Aug 02:21 PDT 2016, Lee Jones wrote: > There is little point wasting CPU cycles completing integrity checking > (i.e. ensuring nothing has changed) on the resource table if we *know* > that it will be changed (by us). In this patch we skip resource table > integrity checks if a

Re: [PATCH V3] printk: Create pr_ functions

On Tue, 2016-08-09 at 19:01 +0200, Geert Uytterhoeven wrote: > On Fri, Jun 24, 2016 at 5:46 AM, Joe Perches wrote: > > Using functions instead of macros can reduce overall code size > > by eliminating unnecessary "KERN_SOH" prefixes from > > format strings. > This change, commit

Re: [PATCH V3] printk: Create pr_ functions

On Tue, 2016-08-09 at 19:01 +0200, Geert Uytterhoeven wrote: > On Fri, Jun 24, 2016 at 5:46 AM, Joe Perches wrote: > > Using functions instead of macros can reduce overall code size > > by eliminating unnecessary "KERN_SOH" prefixes from > > format strings. > This change, commit 874f9c7da9a4acbc1

Re: [PATCH v4 1/3] locking/mutex: Add waiter parameter to mutex_optimistic_spin()

On 08/08/2016 01:26 PM, Peter Zijlstra wrote: On Mon, Jul 18, 2016 at 04:39:24PM -0400, Waiman Long wrote: @@ -302,22 +306,42 @@ static inline bool mutex_try_to_acquire(struct mutex *lock) * * Returns true when the lock was taken, otherwise false, indicating * that we need to jump to

Re: [PATCH v4 1/3] locking/mutex: Add waiter parameter to mutex_optimistic_spin()

On 08/08/2016 01:26 PM, Peter Zijlstra wrote: On Mon, Jul 18, 2016 at 04:39:24PM -0400, Waiman Long wrote: @@ -302,22 +306,42 @@ static inline bool mutex_try_to_acquire(struct mutex *lock) * * Returns true when the lock was taken, otherwise false, indicating * that we need to jump to

Re: [PATCH 3/9] remoteproc: core: Remove pointless OOM print

On Thu 04 Aug 02:21 PDT 2016, Lee Jones wrote: > These types of error prints are superfluous. The system will > pick up on OOM issues and let the user know. > > Signed-off-by: Lee Jones Acked-by: Bjorn Andersson Although, I think we should

Re: [PATCH 3/9] remoteproc: core: Remove pointless OOM print

On Thu 04 Aug 02:21 PDT 2016, Lee Jones wrote: > These types of error prints are superfluous. The system will > pick up on OOM issues and let the user know. > > Signed-off-by: Lee Jones Acked-by: Bjorn Andersson Although, I think we should drop the "mapping" object. We have all the

Re: [PATCH 2/2] ARM: imx6: mark GPC node as not populated after irq init to probe pm domain driver

On Tue, Aug 09, 2016 at 04:18:52PM +0200, Philipp Zabel wrote: > Since IRQCHIP_DECLARE now flags the GPC node as already populated, the > GPC power domain driver is never probed unless we clear the flag again. > > Fixes: 15cc2ed6dcf9 ("of/irq: Mark initialised interrupt controllers as >

Re: [PATCH 2/2] ARM: imx6: mark GPC node as not populated after irq init to probe pm domain driver

On Tue, Aug 09, 2016 at 04:18:52PM +0200, Philipp Zabel wrote: > Since IRQCHIP_DECLARE now flags the GPC node as already populated, the > GPC power domain driver is never probed unless we clear the flag again. > > Fixes: 15cc2ed6dcf9 ("of/irq: Mark initialised interrupt controllers as >

Re: [PATCH] of: Delete an unnecessary check before the function call "of_node_put"

On Tue, Jul 19, 2016 at 10:52:12PM +0200, SF Markus Elfring wrote: > From: Markus Elfring > Date: Tue, 19 Jul 2016 22:42:22 +0200 > > The of_node_put() function tests whether its argument is NULL > and then returns immediately. > Thus the test around the call is

Re: [PATCH] of: Delete an unnecessary check before the function call "of_node_put"

On Tue, Jul 19, 2016 at 10:52:12PM +0200, SF Markus Elfring wrote: > From: Markus Elfring > Date: Tue, 19 Jul 2016 22:42:22 +0200 > > The of_node_put() function tests whether its argument is NULL > and then returns immediately. > Thus the test around the call is not needed. > > This issue was

4.7.0: RCU stall in nf_conntrack

Hi, I just experienced network hangup with 4.7.0, it happened shortly after resume from hibernate: [201988.443552] INFO: rcu_preempt detected stalls on CPUs/tasks: [201988.443556] Tasks blocked on level-0 rcu_node (CPUs 0-3): P14563 [201988.443557] (detected by 3, t=18002

4.7.0: RCU stall in nf_conntrack

Hi, I just experienced network hangup with 4.7.0, it happened shortly after resume from hibernate: [201988.443552] INFO: rcu_preempt detected stalls on CPUs/tasks: [201988.443556] Tasks blocked on level-0 rcu_node (CPUs 0-3): P14563 [201988.443557] (detected by 3, t=18002

Re: [PATCH 2/9] remoteproc: core: Trivial: Improve error checking, spelling and debug prints

On Thu 04 Aug 02:21 PDT 2016, Lee Jones wrote: > Trivial patch to clean up a couple of minor misgivings. > > Signed-off-by: Lee Jones Acked-by: Bjorn Andersson Although as I hope to stack this series ontop of the auto-boot there will be some

Re: [PATCH 2/9] remoteproc: core: Trivial: Improve error checking, spelling and debug prints

On Thu 04 Aug 02:21 PDT 2016, Lee Jones wrote: > Trivial patch to clean up a couple of minor misgivings. > > Signed-off-by: Lee Jones Acked-by: Bjorn Andersson Although as I hope to stack this series ontop of the auto-boot there will be some minor conflicts here. Regards, Bjorn > --- >

Re: [Patch v3 03/11] driver/edac/mpc85xx_edac: Drop setting/clearing RFXE bit in HID1

On 08/08/2016 11:56 PM, Borislav Petkov wrote: > On Tue, Aug 09, 2016 at 05:06:39AM +, york sun wrote: >> It is uncorrectable. DDR controller can only report the error. I don't >> believe EDAC driver can do more. For the same reason I said we can leave >> RXFE as is, even for e500v1 case (with

Re: [Patch v3 03/11] driver/edac/mpc85xx_edac: Drop setting/clearing RFXE bit in HID1

On 08/08/2016 11:56 PM, Borislav Petkov wrote: > On Tue, Aug 09, 2016 at 05:06:39AM +, york sun wrote: >> It is uncorrectable. DDR controller can only report the error. I don't >> believe EDAC driver can do more. For the same reason I said we can leave >> RXFE as is, even for e500v1 case (with

[RFC] dm-crypt: add ability to use keys from the kernel key retention service

The kernel key service is a generic way to store keys for the use of other subsystems. Currently there is no way to use kernel keys in dm-crypt. This patch aims to fix that. Instead of key userspace may pass a key description with preceding ':'. So message that constructs encryption mapping now

[RFC] dm-crypt: add ability to use keys from the kernel key retention service

The kernel key service is a generic way to store keys for the use of other subsystems. Currently there is no way to use kernel keys in dm-crypt. This patch aims to fix that. Instead of key userspace may pass a key description with preceding ':'. So message that constructs encryption mapping now

Re: [PATCH] net: dsa: b53: constify xfrm_replay structures

On Tue, 9 Aug 2016, Florian Fainelli wrote: > On 08/09/2016 09:58 AM, Julia Lawall wrote: > > The xfrm_replay structures are never modified, so declare them as const. > > You mean b53_io_ops here, right? Oops. I sent a v2. julia > Other than that LTGM, but this will > have to wait for

Re: [PATCH] net: dsa: b53: constify xfrm_replay structures

On Tue, 9 Aug 2016, Florian Fainelli wrote: > On 08/09/2016 09:58 AM, Julia Lawall wrote: > > The xfrm_replay structures are never modified, so declare them as const. > > You mean b53_io_ops here, right? Oops. I sent a v2. julia > Other than that LTGM, but this will > have to wait for

Re: [PATCH 1/9] remoteproc: core: Ensure error message is clear

On Thu 04 Aug 02:21 PDT 2016, Lee Jones wrote: > Before this patch, the dma_alloc_coherent() failure path printed out: > > "dma_alloc_coherent err: 16760832" > > ... alluding to the Linux error code being 16760832, but seeing as > Linux error codes are all negative, this looks like a

Re: [PATCH 1/9] remoteproc: core: Ensure error message is clear

On Thu 04 Aug 02:21 PDT 2016, Lee Jones wrote: > Before this patch, the dma_alloc_coherent() failure path printed out: > > "dma_alloc_coherent err: 16760832" > > ... alluding to the Linux error code being 16760832, but seeing as > Linux error codes are all negative, this looks like a

<    1   2   3   4   5   6   7   8   9   10   >