Re: [PATCH 4/8] x86/platform/UV: Add Support for UV4 Hubless NMIs

* Mike Travis wrote: > --- linux.orig/arch/x86/kernel/apic/x2apic_uv_x.c > +++ linux/arch/x86/kernel/apic/x2apic_uv_x.c > @@ -1529,6 +1529,8 @@ void __init uv_system_init(void) > uv_system_init_hub(); > > /* Initialize UV hubless system here */ > + else

Re: [PATCH 4/8] x86/platform/UV: Add Support for UV4 Hubless NMIs

* Mike Travis wrote: > --- linux.orig/arch/x86/kernel/apic/x2apic_uv_x.c > +++ linux/arch/x86/kernel/apic/x2apic_uv_x.c > @@ -1529,6 +1529,8 @@ void __init uv_system_init(void) > uv_system_init_hub(); > > /* Initialize UV hubless system here */ > + else > +

Re: [PATCHv4 3/5] pinctrl: mvebu: pinctrl driver for 98DX3236 SoC

On 13/01/17 22:54, Sebastian Hesselbarth wrote: > On 13.01.2017 10:12, Chris Packham wrote: >> From: Kalyan Kinthada >> >> This pinctrl driver supports the 98DX3236, 98DX3336 and 98DX4251 SoCs >> from Marvell. >> >> Signed-off-by: Kalyan Kinthada

Re: [PATCHv4 3/5] pinctrl: mvebu: pinctrl driver for 98DX3236 SoC

On 13/01/17 22:54, Sebastian Hesselbarth wrote: > On 13.01.2017 10:12, Chris Packham wrote: >> From: Kalyan Kinthada >> >> This pinctrl driver supports the 98DX3236, 98DX3336 and 98DX4251 SoCs >> from Marvell. >> >> Signed-off-by: Kalyan Kinthada >> Signed-off-by: Chris Packham >> Acked-by: Rob

Re: [f2fs-dev] [PATCH 6/6] f2fs: show # of on-going flush and discard bios

Hi Jaegeuk, On 2017/1/13 6:44, Jaegeuk Kim wrote: This patch adds stat information for flush and discard commands. Signed-off-by: Jaegeuk Kim --- fs/f2fs/debug.c | 7 +-- fs/f2fs/f2fs.h| 3 ++- fs/f2fs/segment.c | 4 3 files changed, 11 insertions(+), 3

Re: [f2fs-dev] [PATCH 6/6] f2fs: show # of on-going flush and discard bios

Hi Jaegeuk, On 2017/1/13 6:44, Jaegeuk Kim wrote: This patch adds stat information for flush and discard commands. Signed-off-by: Jaegeuk Kim --- fs/f2fs/debug.c | 7 +-- fs/f2fs/f2fs.h| 3 ++- fs/f2fs/segment.c | 4 3 files changed, 11 insertions(+), 3 deletions(-) diff

Re: [PATCH v9 4/4] console: Make persistent scrollback a boot parameter

On Fri, Jan 13, 2017 at 09:00:34PM +0100, Manuel Schölling wrote: > On Tue, 2017-01-10 at 23:58 +0100, Adam Borowski wrote: > > On Tue, Jan 10, 2017 at 10:28:38PM +0100, Manuel Schölling wrote: > > > The impact of the persistent scrollback feature on the code size is > > > rather small, so the

Re: [PATCH v9 4/4] console: Make persistent scrollback a boot parameter

On Fri, Jan 13, 2017 at 09:00:34PM +0100, Manuel Schölling wrote: > On Tue, 2017-01-10 at 23:58 +0100, Adam Borowski wrote: > > On Tue, Jan 10, 2017 at 10:28:38PM +0100, Manuel Schölling wrote: > > > The impact of the persistent scrollback feature on the code size is > > > rather small, so the

Re: [PATCH 4.4 00/27] 4.4.43-stable review

On Fri, Jan 13, 2017 at 12:19:08PM -0800, Guenter Roeck wrote: > On Fri, Jan 13, 2017 at 12:38:17PM +0100, Greg Kroah-Hartman wrote: > > This is the start of the stable review cycle for the 4.4.43 release. > > There are 27 patches in this series, all will be posted as a response > > to this one.

Re: [PATCH 4.9 00/59] 4.9.4-stable review

On Fri, Jan 13, 2017 at 12:20:20PM -0800, Guenter Roeck wrote: > On Fri, Jan 13, 2017 at 01:01:07PM +0100, Greg Kroah-Hartman wrote: > > This is the start of the stable review cycle for the 4.9.4 release. > > There are 59 patches in this series, all will be posted as a response > > to this one.

Re: [PATCH 4.9 00/59] 4.9.4-stable review

On Fri, Jan 13, 2017 at 02:58:09PM -0700, Shuah Khan wrote: > On 01/13/2017 05:01 AM, Greg Kroah-Hartman wrote: > > This is the start of the stable review cycle for the 4.9.4 release. > > There are 59 patches in this series, all will be posted as a response > > to this one. If anyone has any

Re: [PATCH 4.4 00/27] 4.4.43-stable review

On Fri, Jan 13, 2017 at 12:19:08PM -0800, Guenter Roeck wrote: > On Fri, Jan 13, 2017 at 12:38:17PM +0100, Greg Kroah-Hartman wrote: > > This is the start of the stable review cycle for the 4.4.43 release. > > There are 27 patches in this series, all will be posted as a response > > to this one.

Re: [PATCH 4.9 00/59] 4.9.4-stable review

On Fri, Jan 13, 2017 at 12:20:20PM -0800, Guenter Roeck wrote: > On Fri, Jan 13, 2017 at 01:01:07PM +0100, Greg Kroah-Hartman wrote: > > This is the start of the stable review cycle for the 4.9.4 release. > > There are 59 patches in this series, all will be posted as a response > > to this one.

Re: [PATCH 4.9 00/59] 4.9.4-stable review

On Fri, Jan 13, 2017 at 02:58:09PM -0700, Shuah Khan wrote: > On 01/13/2017 05:01 AM, Greg Kroah-Hartman wrote: > > This is the start of the stable review cycle for the 4.9.4 release. > > There are 59 patches in this series, all will be posted as a response > > to this one. If anyone has any

[PATCH v1 1/3] dt: bindings: add documentation for zx2967 family reset controller

This patch adds dt-binding documentation for zx2967 family reset controller. Signed-off-by: Baoyou Xie --- .../devicetree/bindings/reset/zte,zx2967-reset.txt | 20 1 file changed, 20 insertions(+) create mode 100644

[PATCH v1 2/3] MAINTAINERS: add zx2967 reset controller driver to ARM ZTE architecture

Add the zx2967 reset controller driver as maintained by ARM ZTE architecture maintainers, as they're parts of the core IP. Signed-off-by: Baoyou Xie --- MAINTAINERS | 2 ++ 1 file changed, 2 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index 2793808..08f8155

[PATCH v1 1/3] dt: bindings: add documentation for zx2967 family reset controller

This patch adds dt-binding documentation for zx2967 family reset controller. Signed-off-by: Baoyou Xie --- .../devicetree/bindings/reset/zte,zx2967-reset.txt | 20 1 file changed, 20 insertions(+) create mode 100644

[PATCH v1 2/3] MAINTAINERS: add zx2967 reset controller driver to ARM ZTE architecture

Add the zx2967 reset controller driver as maintained by ARM ZTE architecture maintainers, as they're parts of the core IP. Signed-off-by: Baoyou Xie --- MAINTAINERS | 2 ++ 1 file changed, 2 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index 2793808..08f8155 100644 --- a/MAINTAINERS

[PATCH v1 3/3] reset: zx2967: add reset controller driver for ZTE's zx2967 family

This patch adds reset controller driver for ZTE's zx2967 family. Signed-off-by: Baoyou Xie --- drivers/reset/Kconfig| 6 ++ drivers/reset/Makefile | 1 + drivers/reset/reset-zx2967.c | 136 +++ 3 files changed, 143

[PATCH v1 3/3] reset: zx2967: add reset controller driver for ZTE's zx2967 family

This patch adds reset controller driver for ZTE's zx2967 family. Signed-off-by: Baoyou Xie --- drivers/reset/Kconfig| 6 ++ drivers/reset/Makefile | 1 + drivers/reset/reset-zx2967.c | 136 +++ 3 files changed, 143 insertions(+) create

Re: [PATCH 14/17] spi/topcliff-pch: Adjust six checks for null pointers

On Fri, Jan 13, 2017 at 06:24:22PM +0100, SF Markus Elfring wrote: > From: Markus Elfring > Date: Fri, 13 Jan 2017 16:16:05 +0100 > MIME-Version: 1.0 > Content-Type: text/plain; charset=UTF-8 > Content-Transfer-Encoding: 8bit > > The script "checkpatch.pl" pointed

Re: [PATCH 14/17] spi/topcliff-pch: Adjust six checks for null pointers

On Fri, Jan 13, 2017 at 06:24:22PM +0100, SF Markus Elfring wrote: > From: Markus Elfring > Date: Fri, 13 Jan 2017 16:16:05 +0100 > MIME-Version: 1.0 > Content-Type: text/plain; charset=UTF-8 > Content-Transfer-Encoding: 8bit > > The script "checkpatch.pl" pointed information out like the

Re: [PATCH] printk: Correctly handle preemption in console_unlock()

On (01/13/17 14:15), Petr Mladek wrote: > Some console drivers code calls console_conditional_schedule() > that looks at @console_may_schedule. The value must be cleared > when the drivers are called from console_unlock() with > interrupts disabled. But rescheduling is fine when the same > code is

Re: [PATCH] printk: Correctly handle preemption in console_unlock()

On (01/13/17 14:15), Petr Mladek wrote: > Some console drivers code calls console_conditional_schedule() > that looks at @console_may_schedule. The value must be cleared > when the drivers are called from console_unlock() with > interrupts disabled. But rescheduling is fine when the same > code is

Re: [PATCH 05/62] watchdog: bcm2835_wdt: Convert to use device managed functions and other improvements

Guenter Roeck writes: > Use device managed functions to simplify error handling, reduce > source code size, improve readability, and reduce the likelyhood of bugs. > Other improvements as listed below. > > The conversion was done automatically with coccinelle using the >

Re: [PATCH 05/62] watchdog: bcm2835_wdt: Convert to use device managed functions and other improvements

Guenter Roeck writes: > Use device managed functions to simplify error handling, reduce > source code size, improve readability, and reduce the likelyhood of bugs. > Other improvements as listed below. > > The conversion was done automatically with coccinelle using the > following semantic

[PATCH 9/9] slab: remove slub sysfs interface files early for empty memcg caches

With kmem cgroup support enabled, kmem_caches can be created and destroyed frequently and a great number of near empty kmem_caches can accumulate if there are a lot of transient cgroups and the system is not under memory pressure. When memory reclaim starts under such conditions, it can lead to

[PATCHSET] slab: make memcg slab destruction scalable

With kmem cgroup support enabled, kmem_caches can be created and destroyed frequently and a great number of near empty kmem_caches can accumulate if there are a lot of transient cgroups and the system is not under memory pressure. When memory reclaim starts under such conditions, it can lead to

[PATCH 8/9] slab: remove synchronous synchronize_sched() from memcg cache deactivation path

With kmem cgroup support enabled, kmem_caches can be created and destroyed frequently and a great number of near empty kmem_caches can accumulate if there are a lot of transient cgroups and the system is not under memory pressure. When memory reclaim starts under such conditions, it can lead to

[PATCH 3/9] slab: simplify shutdown_memcg_caches()

shutdown_memcg_caches() shuts down all memcg caches associated with a root cache. It first walks the index table clearing and shutting down each entry and then shuts down the ones on root_cache->memcg_params.list. As active caches are on both the table and the list, they're stashed away from the

[PATCH 9/9] slab: remove slub sysfs interface files early for empty memcg caches

With kmem cgroup support enabled, kmem_caches can be created and destroyed frequently and a great number of near empty kmem_caches can accumulate if there are a lot of transient cgroups and the system is not under memory pressure. When memory reclaim starts under such conditions, it can lead to

[PATCHSET] slab: make memcg slab destruction scalable

With kmem cgroup support enabled, kmem_caches can be created and destroyed frequently and a great number of near empty kmem_caches can accumulate if there are a lot of transient cgroups and the system is not under memory pressure. When memory reclaim starts under such conditions, it can lead to

[PATCH 8/9] slab: remove synchronous synchronize_sched() from memcg cache deactivation path

With kmem cgroup support enabled, kmem_caches can be created and destroyed frequently and a great number of near empty kmem_caches can accumulate if there are a lot of transient cgroups and the system is not under memory pressure. When memory reclaim starts under such conditions, it can lead to

[PATCH 3/9] slab: simplify shutdown_memcg_caches()

shutdown_memcg_caches() shuts down all memcg caches associated with a root cache. It first walks the index table clearing and shutting down each entry and then shuts down the ones on root_cache->memcg_params.list. As active caches are on both the table and the list, they're stashed away from the

[PATCH 5/9] slab: link memcg kmem_caches on their associated memory cgroup

With kmem cgroup support enabled, kmem_caches can be created and destroyed frequently and a great number of near empty kmem_caches can accumulate if there are a lot of transient cgroups and the system is not under memory pressure. When memory reclaim starts under such conditions, it can lead to

[PATCH 2/9] slab: remove synchronous rcu_barrier() call in memcg cache release path

With kmem cgroup support enabled, kmem_caches can be created and destroyed frequently and a great number of near empty kmem_caches can accumulate if there are a lot of transient cgroups and the system is not under memory pressure. When memory reclaim starts under such conditions, it can lead to

[PATCH 5/9] slab: link memcg kmem_caches on their associated memory cgroup

With kmem cgroup support enabled, kmem_caches can be created and destroyed frequently and a great number of near empty kmem_caches can accumulate if there are a lot of transient cgroups and the system is not under memory pressure. When memory reclaim starts under such conditions, it can lead to

[PATCH 2/9] slab: remove synchronous rcu_barrier() call in memcg cache release path

With kmem cgroup support enabled, kmem_caches can be created and destroyed frequently and a great number of near empty kmem_caches can accumulate if there are a lot of transient cgroups and the system is not under memory pressure. When memory reclaim starts under such conditions, it can lead to

[PATCH 1/9] Revert "slub: move synchronize_sched out of slab_mutex on shrink"

This reverts commit 89e364db71fb5e7fc8d93228152abfa67daf35fa. With kmem cgroup support enabled, kmem_caches can be created and destroyed frequently and a great number of near empty kmem_caches can accumulate if there are a lot of transient cgroups and the system is not under memory pressure.

[PATCH 6/9] slab: don't put memcg caches on slab_caches list

With kmem cgroup support enabled, kmem_caches can be created and destroyed frequently and a great number of near empty kmem_caches can accumulate if there are a lot of transient cgroups and the system is not under memory pressure. When memory reclaim starts under such conditions, it can lead to

[PATCH 7/9] slab: introduce __kmemcg_cache_deactivate()

__kmem_cache_shrink() is called with %true @deactivate only for memcg caches. Remove @deactivate from __kmem_cache_shrink() and introduce __kmemcg_cache_deactivate() instead. Each memcg-supporting allocator should implement it and it should deactivate and drain the cache. This is to allow memcg

[PATCH 4/9] slab: reorganize memcg_cache_params

We're gonna change how memcg caches are iterated. In preparation, clean up and reorganize memcg_cache_params. * The shared ->list is replaced by ->children in root and ->children_node in children. * ->is_root_cache is removed. Instead ->root_cache is moved out of the child union and now

[PATCH 7/9] slab: introduce __kmemcg_cache_deactivate()

__kmem_cache_shrink() is called with %true @deactivate only for memcg caches. Remove @deactivate from __kmem_cache_shrink() and introduce __kmemcg_cache_deactivate() instead. Each memcg-supporting allocator should implement it and it should deactivate and drain the cache. This is to allow memcg

[PATCH 4/9] slab: reorganize memcg_cache_params

We're gonna change how memcg caches are iterated. In preparation, clean up and reorganize memcg_cache_params. * The shared ->list is replaced by ->children in root and ->children_node in children. * ->is_root_cache is removed. Instead ->root_cache is moved out of the child union and now

[PATCH 1/9] Revert "slub: move synchronize_sched out of slab_mutex on shrink"

This reverts commit 89e364db71fb5e7fc8d93228152abfa67daf35fa. With kmem cgroup support enabled, kmem_caches can be created and destroyed frequently and a great number of near empty kmem_caches can accumulate if there are a lot of transient cgroups and the system is not under memory pressure.

[PATCH 6/9] slab: don't put memcg caches on slab_caches list

With kmem cgroup support enabled, kmem_caches can be created and destroyed frequently and a great number of near empty kmem_caches can accumulate if there are a lot of transient cgroups and the system is not under memory pressure. When memory reclaim starts under such conditions, it can lead to

Re: [PATCH] platform/x86: Add IMS/ZII SCU driver

On 01/13/2017 03:15 PM, Florian Fainelli wrote: On 01/13/2017 08:38 AM, Andy Shevchenko wrote: On Wed, Jan 11, 2017 at 11:26 PM, Florian Fainelli wrote: From: Guenter Roeck This patch adds support for the IMS (now Zodiac Inflight Innovations) SCU

Re: [PATCH] platform/x86: Add IMS/ZII SCU driver

On 01/13/2017 03:15 PM, Florian Fainelli wrote: On 01/13/2017 08:38 AM, Andy Shevchenko wrote: On Wed, Jan 11, 2017 at 11:26 PM, Florian Fainelli wrote: From: Guenter Roeck This patch adds support for the IMS (now Zodiac Inflight Innovations) SCU Generation 1/2/3 platform driver. This

[PATCH v6 1/3] dmaengine: xilinx_dma: Check for channel idle state before submitting dma descriptor

Add variable for checking channel idle state to ensure that dma descriptor is not Submitted when DMA engine is in progress. This will avoids the pollling for a bit in the status register to know Dma state in the driver hot path. Reviewed-by: Jose Abreu Signed-off-by:

[PATCH v6 0/3] dmaengine: xilinx_dma: Bug fixes

This patch series fixes below bugs in DMA and VDMA IP's ---> Do not start VDMA until frame buffer is processed by the h/w ---> Fix bug in Multi frame sotres handling in VDMA ---> Fix issues w.r.to multi frame descriptors submit with AXI DMA S2MM(recv) Side. Kedareswara rao Appana (3):

[PATCH v6 1/3] dmaengine: xilinx_dma: Check for channel idle state before submitting dma descriptor

Add variable for checking channel idle state to ensure that dma descriptor is not Submitted when DMA engine is in progress. This will avoids the pollling for a bit in the status register to know Dma state in the driver hot path. Reviewed-by: Jose Abreu Signed-off-by: Kedareswara rao Appana

[PATCH v6 0/3] dmaengine: xilinx_dma: Bug fixes

This patch series fixes below bugs in DMA and VDMA IP's ---> Do not start VDMA until frame buffer is processed by the h/w ---> Fix bug in Multi frame sotres handling in VDMA ---> Fix issues w.r.to multi frame descriptors submit with AXI DMA S2MM(recv) Side. Kedareswara rao Appana (3):

[PATCH v6 2/3] dmaeninge: xilinx_dma: Fix bug in multiple frame stores scenario in vdma

When VDMA is configured for more than one frame in the h/w. For example h/w is configured for n number of frames, user Submits n number of frames and triggered the DMA using issue_pending API. In the current driver flow we are submitting one frame at a time, But we should submit all the n number

[PATCH v6 3/3] dmaengine: xilinx_dma: Fix race condition in the driver for multiple descriptor scenario

As per AXI DMA spec the software must not move the tail pointer to a location That has not been updated (next descriptor field of the h/w descriptor Should always point to a valid address). When user submits multiple descriptors on the recv side, with the Current driver flow the last buffer

[PATCH v6 2/3] dmaeninge: xilinx_dma: Fix bug in multiple frame stores scenario in vdma

When VDMA is configured for more than one frame in the h/w. For example h/w is configured for n number of frames, user Submits n number of frames and triggered the DMA using issue_pending API. In the current driver flow we are submitting one frame at a time, But we should submit all the n number

[PATCH v6 3/3] dmaengine: xilinx_dma: Fix race condition in the driver for multiple descriptor scenario

As per AXI DMA spec the software must not move the tail pointer to a location That has not been updated (next descriptor field of the h/w descriptor Should always point to a valid address). When user submits multiple descriptors on the recv side, with the Current driver flow the last buffer

Re: [RFC/PATCH] ftrace: Allow to change size of function graph filters

On Sat, 14 Jan 2017 13:20:00 +0900 Namhyung Kim wrote: > But I'm not sure how to synchronize hash table manipulations. It > seems synchronize_sched() is not good enough for function graph > tracer, right? So I limited changing filter size only when no tracer > is used,

Re: [RFC/PATCH] ftrace: Allow to change size of function graph filters

On Sat, 14 Jan 2017 13:20:00 +0900 Namhyung Kim wrote: > But I'm not sure how to synchronize hash table manipulations. It > seems synchronize_sched() is not good enough for function graph > tracer, right? So I limited changing filter size only when no tracer > is used, but is it ok to have

[Update][PATCH v5 2/9] mm/swap: Add cluster lock

This patch is to reduce the lock contention of swap_info_struct->lock via using a more fine grained lock in swap_cluster_info for some swap operations. swap_info_struct->lock is heavily contended if multiple processes reclaim pages simultaneously. Because there is only one lock for each swap

[Update][PATCH v5 2/9] mm/swap: Add cluster lock

This patch is to reduce the lock contention of swap_info_struct->lock via using a more fine grained lock in swap_cluster_info for some swap operations. swap_info_struct->lock is heavily contended if multiple processes reclaim pages simultaneously. Because there is only one lock for each swap

Re: [PATCH v7 00/15] ACPI platform MSI support and its example mbigen

Hi Wei, On 2017/1/13 22:11, Wei Xu wrote: > Hi Hanjun, > > On 2017/1/11 15:06, Hanjun Guo wrote: >> With platform msi support landed in the kernel, and the introduction >> of IORT for GICv3 ITS (PCI MSI) and SMMU, the framework for platform msi >> is ready, this patch set add few patches to

Re: [PATCH v7 00/15] ACPI platform MSI support and its example mbigen

Hi Wei, On 2017/1/13 22:11, Wei Xu wrote: > Hi Hanjun, > > On 2017/1/11 15:06, Hanjun Guo wrote: >> With platform msi support landed in the kernel, and the introduction >> of IORT for GICv3 ITS (PCI MSI) and SMMU, the framework for platform msi >> is ready, this patch set add few patches to

Re: [RFC/PATCH] ftrace: Allow to change size of function graph filters

Hi Steve, On Fri, Jan 13, 2017 at 11:16:18AM -0500, Steven Rostedt wrote: > On Fri, 13 Jan 2017 13:22:43 +0900 > Namhyung Kim wrote: > > > It's currently fixed to 32 and it ignores when user gives a pattern > > which match to functions more than the size. So filtering like

Re: [RFC/PATCH] ftrace: Allow to change size of function graph filters

Hi Steve, On Fri, Jan 13, 2017 at 11:16:18AM -0500, Steven Rostedt wrote: > On Fri, 13 Jan 2017 13:22:43 +0900 > Namhyung Kim wrote: > > > It's currently fixed to 32 and it ignores when user gives a pattern > > which match to functions more than the size. So filtering like all > > system calls

Re: [PATCH v7 09/15] ACPI: platform-msi: retrieve dev id from IORT

Hi Lorenzo, On 2017/1/13 20:11, Lorenzo Pieralisi wrote: > On Wed, Jan 11, 2017 at 11:06:33PM +0800, Hanjun Guo wrote: >> For devices connecting to ITS, it needs dev id to identify itself, and >> this dev id is represented in the IORT table in named component node >> [1] for platform devices, so

Re: [PATCH v7 09/15] ACPI: platform-msi: retrieve dev id from IORT

Hi Lorenzo, On 2017/1/13 20:11, Lorenzo Pieralisi wrote: > On Wed, Jan 11, 2017 at 11:06:33PM +0800, Hanjun Guo wrote: >> For devices connecting to ITS, it needs dev id to identify itself, and >> this dev id is represented in the IORT table in named component node >> [1] for platform devices, so

Re: [PATCH] can: Fix kernel panic at security_sock_rcv_skb

On Thu 12.Jan'17 at 17:33:38 +0100, Oliver Hartkopp wrote: On 01/12/2017 02:01 PM, Eric Dumazet wrote: On Thu, 2017-01-12 at 09:22 +0100, Oliver Hartkopp wrote: But my main concern is: The reason why can_rx_delete_receiver() was introduced was the need to remove a huge number of receivers

Re: [PATCH] can: Fix kernel panic at security_sock_rcv_skb

On Thu 12.Jan'17 at 17:33:38 +0100, Oliver Hartkopp wrote: On 01/12/2017 02:01 PM, Eric Dumazet wrote: On Thu, 2017-01-12 at 09:22 +0100, Oliver Hartkopp wrote: But my main concern is: The reason why can_rx_delete_receiver() was introduced was the need to remove a huge number of receivers

Re: 4.10-rc3, firmware loading via user space helper crashes if firmware not present

On Fri, 13 Jan 2017 13:32:58 -0800, Jakub Kicinski wrote: > If one requests a FW which does not exist in the FS and the user space > helper is used then fw_load_abort() will be called twice which leads to > NULL-deref. > > It will be called once in firmware_loading_store() (handling the -1 >

Re: 4.10-rc3, firmware loading via user space helper crashes if firmware not present

On Fri, 13 Jan 2017 13:32:58 -0800, Jakub Kicinski wrote: > If one requests a FW which does not exist in the FS and the user space > helper is used then fw_load_abort() will be called twice which leads to > NULL-deref. > > It will be called once in firmware_loading_store() (handling the -1 >

Re: [PATCH v7 08/15] ACPI: IORT: rename iort_node_map_rid() to make it generic

On 2017/1/13 19:47, Lorenzo Pieralisi wrote: > On Wed, Jan 11, 2017 at 11:06:32PM +0800, Hanjun Guo wrote: >> iort_node_map_rid() was designed for both PCI and platform >> device, but the rid means requester id is for ITS mappings, > I do not understand what this means sorry. > >> rename

Re: [PATCH v7 08/15] ACPI: IORT: rename iort_node_map_rid() to make it generic

On 2017/1/13 19:47, Lorenzo Pieralisi wrote: > On Wed, Jan 11, 2017 at 11:06:32PM +0800, Hanjun Guo wrote: >> iort_node_map_rid() was designed for both PCI and platform >> device, but the rid means requester id is for ITS mappings, > I do not understand what this means sorry. > >> rename

Re: [PATCH v7 12/15] msi: platform: make platform_msi_create_device_domain() ACPI aware

On 2017/1/13 18:45, Lorenzo Pieralisi wrote: > On Wed, Jan 11, 2017 at 11:06:36PM +0800, Hanjun Guo wrote: >> platform_msi_create_device_domain() is used to ctreate >> irqdomain for the device such as irqchip mbigen generating >> the MSIs, it's almost ready for ACPI use except >>

Re: [PATCH v7 12/15] msi: platform: make platform_msi_create_device_domain() ACPI aware

On 2017/1/13 18:45, Lorenzo Pieralisi wrote: > On Wed, Jan 11, 2017 at 11:06:36PM +0800, Hanjun Guo wrote: >> platform_msi_create_device_domain() is used to ctreate >> irqdomain for the device such as irqchip mbigen generating >> the MSIs, it's almost ready for ACPI use except >>

Re: [PATCH v7 15/15] irqchip: mbigen: Add ACPI support

Hi Lorenzo, On 2017/1/13 18:21, Lorenzo Pieralisi wrote: > On Wed, Jan 11, 2017 at 11:06:39PM +0800, Hanjun Guo wrote: >> With the preparation of platform msi support and interrupt producer >> in DSDT, we can add mbigen ACPI support now. >> >> We are using _PRS methd to indicate number of irq

Re: [PATCH v7 15/15] irqchip: mbigen: Add ACPI support

Hi Lorenzo, On 2017/1/13 18:21, Lorenzo Pieralisi wrote: > On Wed, Jan 11, 2017 at 11:06:39PM +0800, Hanjun Guo wrote: >> With the preparation of platform msi support and interrupt producer >> in DSDT, we can add mbigen ACPI support now. >> >> We are using _PRS methd to indicate number of irq

Re: [PATCH 5/6] treewide: use kv[mz]alloc* rather than opencoded variants

On 2017/01/13 2:29, Michal Hocko wrote: > Ilya has noticed that I've screwed up some k[zc]alloc conversions and > didn't use the kvzalloc. This is an updated patch with some acks > collected on the way > --- > From a7b89c6d0a3c685045e37740c8f97b065f37e0a4 Mon Sep 17 00:00:00 2001 > From: Michal

Re: [PATCH 5/6] treewide: use kv[mz]alloc* rather than opencoded variants

On 2017/01/13 2:29, Michal Hocko wrote: > Ilya has noticed that I've screwed up some k[zc]alloc conversions and > didn't use the kvzalloc. This is an updated patch with some acks > collected on the way > --- > From a7b89c6d0a3c685045e37740c8f97b065f37e0a4 Mon Sep 17 00:00:00 2001 > From: Michal

Re: [PATCH v7 7/7] perf/amd/iommu: Enable support for multiple IOMMUs

On 1/13/17 18:49, Borislav Petkov wrote: On Fri, Jan 13, 2017 at 05:24:01PM +0700, Suravee Suthikulpanit wrote: IIUC, Perf tools looks at the /sys/devices/x to identify availalble PMUs. Are you planning to have perf tools look at /sys/devices/system/iommu/xxx instead? No, I'm planning

Re: [PATCH v7 7/7] perf/amd/iommu: Enable support for multiple IOMMUs

On 1/13/17 18:49, Borislav Petkov wrote: On Fri, Jan 13, 2017 at 05:24:01PM +0700, Suravee Suthikulpanit wrote: IIUC, Perf tools looks at the /sys/devices/x to identify availalble PMUs. Are you planning to have perf tools look at /sys/devices/system/iommu/xxx instead? No, I'm planning

Re: [PATCH 8/9] serdev: add a tty port controller driver

On Tue, Jan 10, 2017 at 4:04 PM, Pavel Machek wrote: > Hi! > >> +MODULE_AUTHOR("Rob Herring > Missing ">". Actually, this I should drop because this driver can not be a module. The bus can be though. Rob

Re: [PATCH 8/9] serdev: add a tty port controller driver

On Tue, Jan 10, 2017 at 4:04 PM, Pavel Machek wrote: > Hi! > >> +MODULE_AUTHOR("Rob Herring > Missing ">". Actually, this I should drop because this driver can not be a module. The bus can be though. Rob

Re: [PATCH v2 1/2] of: base: add support to find the level of the last cache

On Thu, Jan 12, 2017 at 12:29 PM, Sudeep Holla wrote: > It is useful to have helper function just to get the number of cache > levels for a given logical cpu. We can obtain the same by just checking > the level at which the last cache is present. This patch adds support > to

Re: [PATCH v2 1/2] of: base: add support to find the level of the last cache

On Thu, Jan 12, 2017 at 12:29 PM, Sudeep Holla wrote: > It is useful to have helper function just to get the number of cache > levels for a given logical cpu. We can obtain the same by just checking > the level at which the last cache is present. This patch adds support > to find the level of the

Re: [PATCH 2/6] mm: support __GFP_REPEAT in kvmalloc_node for >=64kB

On 2017/01/13 0:37, Michal Hocko wrote: > diff --git a/drivers/vhost/net.c b/drivers/vhost/net.c > index 5dc34653274a..105cd04c7414 100644 > --- a/drivers/vhost/net.c > +++ b/drivers/vhost/net.c > @@ -797,12 +797,9 @@ static int vhost_net_open(struct inode *inode, struct > file *f) > struct

Re: [PATCH 2/6] mm: support __GFP_REPEAT in kvmalloc_node for >=64kB

On 2017/01/13 0:37, Michal Hocko wrote: > diff --git a/drivers/vhost/net.c b/drivers/vhost/net.c > index 5dc34653274a..105cd04c7414 100644 > --- a/drivers/vhost/net.c > +++ b/drivers/vhost/net.c > @@ -797,12 +797,9 @@ static int vhost_net_open(struct inode *inode, struct > file *f) > struct

Re: [PATCH v3 2/4] dt-bindings: Add TI SCI PM Domains

On Fri, Jan 13, 2017 at 2:28 PM, Dave Gerlach wrote: > On 01/13/2017 01:25 PM, Rob Herring wrote: >> >> On Thu, Jan 12, 2017 at 9:27 AM, Dave Gerlach wrote: >>> >>> Rob, >>> >>> On 01/11/2017 03:34 PM, Rob Herring wrote: On Mon, Jan 9, 2017 at

Re: [PATCH v3 2/4] dt-bindings: Add TI SCI PM Domains

On Fri, Jan 13, 2017 at 2:28 PM, Dave Gerlach wrote: > On 01/13/2017 01:25 PM, Rob Herring wrote: >> >> On Thu, Jan 12, 2017 at 9:27 AM, Dave Gerlach wrote: >>> >>> Rob, >>> >>> On 01/11/2017 03:34 PM, Rob Herring wrote: On Mon, Jan 9, 2017 at 11:57 AM, Dave Gerlach wrote: >

Re: [f2fs-dev] [PATCH 6/6] f2fs: show # of on-going flush and discard bios

Hi Jaegeuk Kim, On 2017/1/13 6:44, Jaegeuk Kim wrote: This patch adds stat information for flush and discard commands. Signed-off-by: Jaegeuk Kim --- fs/f2fs/debug.c | 7 +-- fs/f2fs/f2fs.h| 3 ++- fs/f2fs/segment.c | 4 3 files changed, 11 insertions(+), 3

Re: [f2fs-dev] [PATCH 6/6] f2fs: show # of on-going flush and discard bios

Hi Jaegeuk Kim, On 2017/1/13 6:44, Jaegeuk Kim wrote: This patch adds stat information for flush and discard commands. Signed-off-by: Jaegeuk Kim --- fs/f2fs/debug.c | 7 +-- fs/f2fs/f2fs.h| 3 ++- fs/f2fs/segment.c | 4 3 files changed, 11 insertions(+), 3 deletions(-) diff

[PATCH] mwifiex: don't complain about 'unknown event id: 0x63'

Marvell folks tell me this is a debugging event that the driver doesn't need to handle, but on 8997 w/ firmware 16.68.1.p97, I see several of these sorts of messages at (for instance) boot time: [ 13.825848] mwifiex_pcie :01:00.0: event: unknown event id: 0x63 [ 14.838561] mwifiex_pcie

[PATCH] mwifiex: don't complain about 'unknown event id: 0x63'

Marvell folks tell me this is a debugging event that the driver doesn't need to handle, but on 8997 w/ firmware 16.68.1.p97, I see several of these sorts of messages at (for instance) boot time: [ 13.825848] mwifiex_pcie :01:00.0: event: unknown event id: 0x63 [ 14.838561] mwifiex_pcie

RE: [PATCH v2 00/26] IB: Optimize DMA mapping

> -Original Message- > From: Bart Van Assche [mailto:bart.vanass...@sandisk.com] > Sent: Friday, January 13, 2017 5:00 PM > To: Estrin, Alex ; dledf...@redhat.com > Cc: linux-kernel@vger.kernel.org; linux-r...@vger.kernel.org; > gre...@linuxfoundation.org >

RE: [PATCH v2 00/26] IB: Optimize DMA mapping

> -Original Message- > From: Bart Van Assche [mailto:bart.vanass...@sandisk.com] > Sent: Friday, January 13, 2017 5:00 PM > To: Estrin, Alex ; dledf...@redhat.com > Cc: linux-kernel@vger.kernel.org; linux-r...@vger.kernel.org; > gre...@linuxfoundation.org > Subject: Re: [PATCH v2 00/26]

Re: 4.9.0 regression in pipe-backed iov_iter with systemd-nspawn

On Fri, Jan 13, 2017 at 05:46:34PM -0800, Linus Torvalds wrote: > On Fri, Jan 13, 2017 at 5:24 PM, Al Viro wrote: > > > > Why would advance by 0 change ->iov_offset here? > > That's not my worry. Advancing by zero obviously doesn't change the position. > > But the

Re: 4.9.0 regression in pipe-backed iov_iter with systemd-nspawn

On Fri, Jan 13, 2017 at 05:46:34PM -0800, Linus Torvalds wrote: > On Fri, Jan 13, 2017 at 5:24 PM, Al Viro wrote: > > > > Why would advance by 0 change ->iov_offset here? > > That's not my worry. Advancing by zero obviously doesn't change the position. > > But the _truncation_ of the rest

Re: 4.9.0 regression in pipe-backed iov_iter with systemd-nspawn

On Fri, Jan 13, 2017 at 5:24 PM, Al Viro wrote: > > Why would advance by 0 change ->iov_offset here? That's not my worry. Advancing by zero obviously doesn't change the position. But the _truncation_ of the rest requires iov_offset to be zero in order to actually

Re: 4.9.0 regression in pipe-backed iov_iter with systemd-nspawn

On Fri, Jan 13, 2017 at 5:24 PM, Al Viro wrote: > > Why would advance by 0 change ->iov_offset here? That's not my worry. Advancing by zero obviously doesn't change the position. But the _truncation_ of the rest requires iov_offset to be zero in order to actually truncate everything. So I was

Re: 4.9.0 regression in pipe-backed iov_iter with systemd-nspawn

On Sat, Jan 14, 2017 at 01:24:28AM +, Al Viro wrote: > On Fri, Jan 13, 2017 at 04:59:37PM -0800, Linus Torvalds wrote: > > > EXCEPT. > > > > I don't think "i->iov_offset" is actually correct. If you truncated > > the whole thing, you should have cleared iov_offset too, and that > > never

Re: 4.9.0 regression in pipe-backed iov_iter with systemd-nspawn

On Sat, Jan 14, 2017 at 01:24:28AM +, Al Viro wrote: > On Fri, Jan 13, 2017 at 04:59:37PM -0800, Linus Torvalds wrote: > > > EXCEPT. > > > > I don't think "i->iov_offset" is actually correct. If you truncated > > the whole thing, you should have cleared iov_offset too, and that > > never

  1   2   3   4   5   6   7   8   9   10   >