Re: [PATCH tip/core/rcu 08/20] rcu: Add long-term CPU kicking

2017-01-15 Thread Josh Triplett
On Sat, Jan 14, 2017 at 01:13:09AM -0800, Paul E. McKenney wrote: > Commit d2db185bfee8 ("rcu: Remove short-term CPU kicking") removed > frequent calls to resched_cpu(), which means that the only time > resched_cpu() is invoked is after an RCU CPU stall warning. Although > this is good from an

Re: [PATCH tip/core/rcu 08/20] rcu: Add long-term CPU kicking

2017-01-15 Thread Josh Triplett
On Sat, Jan 14, 2017 at 01:13:09AM -0800, Paul E. McKenney wrote: > Commit d2db185bfee8 ("rcu: Remove short-term CPU kicking") removed > frequent calls to resched_cpu(), which means that the only time > resched_cpu() is invoked is after an RCU CPU stall warning. Although > this is good from an

Re: [PATCH tip/core/rcu 02/20] lockdep: Make RCU suspicious-access splats use pr_err

2017-01-15 Thread Josh Triplett
On Sat, Jan 14, 2017 at 01:13:03AM -0800, Paul E. McKenney wrote: > This commit switches RCU suspicious-access splats use pr_err() > instead of the current INFO printk()s. This change makes it easier > to automatically classify splats. > > Reported-by: Dmitry Vyukov >

Re: [PATCH tip/core/rcu 02/20] lockdep: Make RCU suspicious-access splats use pr_err

2017-01-15 Thread Josh Triplett
On Sat, Jan 14, 2017 at 01:13:03AM -0800, Paul E. McKenney wrote: > This commit switches RCU suspicious-access splats use pr_err() > instead of the current INFO printk()s. This change makes it easier > to automatically classify splats. > > Reported-by: Dmitry Vyukov > Signed-off-by: Paul E.

Re: [PATCH tip/core/rcu 0/6] Dynticks updates for 4.11

2017-01-15 Thread Josh Triplett
On Sat, Jan 14, 2017 at 12:54:06AM -0800, Paul E. McKenney wrote: > Hello! > > This series provides dynticks updates: > > 1-4. Abstract access to the dyntick counter, replacing the current > open-coding of atomic operations. > > 5.Check cond_resched_rcu_qs() state less often to

Re: [PATCH tip/core/rcu 0/6] Dynticks updates for 4.11

2017-01-15 Thread Josh Triplett
On Sat, Jan 14, 2017 at 12:54:06AM -0800, Paul E. McKenney wrote: > Hello! > > This series provides dynticks updates: > > 1-4. Abstract access to the dyntick counter, replacing the current > open-coding of atomic operations. > > 5.Check cond_resched_rcu_qs() state less often to

Re: [PATCH tip/core/rcu 3/6] rcu: Abstract dynticks extended quiescent state enter/exit operations

2017-01-15 Thread Josh Triplett
On Sat, Jan 14, 2017 at 12:54:42AM -0800, Paul E. McKenney wrote: > This commit is the third step towards full abstraction of all accesses > to the ->dynticks counter, implementing the previously open-coded atomic > add of 1 and entry checks in a new rcu_dynticks_eqs_enter() function, and > the

Re: [PATCH tip/core/rcu 3/6] rcu: Abstract dynticks extended quiescent state enter/exit operations

2017-01-15 Thread Josh Triplett
On Sat, Jan 14, 2017 at 12:54:42AM -0800, Paul E. McKenney wrote: > This commit is the third step towards full abstraction of all accesses > to the ->dynticks counter, implementing the previously open-coded atomic > add of 1 and entry checks in a new rcu_dynticks_eqs_enter() function, and > the

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

2017-01-15 Thread Shawn Guo
On Sat, Jan 14, 2017 at 03:05:30PM +0800, Baoyou Xie wrote: > This patch adds reset controller driver for ZTE's zx2967 family. > > Signed-off-by: Baoyou Xie > --- > drivers/reset/Kconfig| 6 ++ > drivers/reset/Makefile | 1 + >

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

2017-01-15 Thread Shawn Guo
On Sat, Jan 14, 2017 at 03:05:30PM +0800, Baoyou Xie wrote: > 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 >

Re: [alsa-devel] [PATCH v2 3/4] ASoC: Intel: Support rt5660 codec for Baytrail

2017-01-15 Thread Shrirang Bagul
On Thu, 2017-01-12 at 08:40 -0600, Pierre-Louis Bossart wrote: > On 1/12/17 6:01 AM, Shrirang Bagul wrote: > > rt5660 and rt5640 are similar codecs so reuse the bytcr_rt5640 driver. > > RT5660 codec is used on Dell Edge IoT Gateways with ACPI ID 10EC3277. > > These devices sport only Line-In and

Re: [alsa-devel] [PATCH v2 3/4] ASoC: Intel: Support rt5660 codec for Baytrail

2017-01-15 Thread Shrirang Bagul
On Thu, 2017-01-12 at 08:40 -0600, Pierre-Louis Bossart wrote: > On 1/12/17 6:01 AM, Shrirang Bagul wrote: > > rt5660 and rt5640 are similar codecs so reuse the bytcr_rt5640 driver. > > RT5660 codec is used on Dell Edge IoT Gateways with ACPI ID 10EC3277. > > These devices sport only Line-In and

Re: [PATCH tip/core/rcu 1/6] rcu: Abstract the dynticks momentary-idle operation

2017-01-15 Thread Josh Triplett
On Sat, Jan 14, 2017 at 12:54:40AM -0800, Paul E. McKenney wrote: > This commit is the first step towards full abstraction of all accesses to > the ->dynticks counter, implementing the previously open-coded atomic add > of two in a new rcu_dynticks_momentary_idle() function. This abstraction >

Re: [PATCH tip/core/rcu 1/6] rcu: Abstract the dynticks momentary-idle operation

2017-01-15 Thread Josh Triplett
On Sat, Jan 14, 2017 at 12:54:40AM -0800, Paul E. McKenney wrote: > This commit is the first step towards full abstraction of all accesses to > the ->dynticks counter, implementing the previously open-coded atomic add > of two in a new rcu_dynticks_momentary_idle() function. This abstraction >

Re: [PATCH v2 2/2] ocfs2: fix deadlock issue when taking inode lock at vfs entry points

2017-01-15 Thread Eric Ren
Hi! On 01/16/2017 02:58 PM, Junxiao Bi wrote: On 01/16/2017 02:42 PM, Eric Ren wrote: Commit 743b5f1434f5 ("ocfs2: take inode lock in ocfs2_iop_set/get_acl()") results in a deadlock, as the author "Tariq Saeed" realized shortly after the patch was merged. The discussion happened here

Re: [PATCH v2 2/2] ocfs2: fix deadlock issue when taking inode lock at vfs entry points

2017-01-15 Thread Eric Ren
Hi! On 01/16/2017 02:58 PM, Junxiao Bi wrote: On 01/16/2017 02:42 PM, Eric Ren wrote: Commit 743b5f1434f5 ("ocfs2: take inode lock in ocfs2_iop_set/get_acl()") results in a deadlock, as the author "Tariq Saeed" realized shortly after the patch was merged. The discussion happened here

Re: [patch v2] mm, memcg: do not retry precharge charges

2017-01-15 Thread Michal Hocko
On Sat 14-01-17 21:42:48, David Rientjes wrote: > On Sat, 14 Jan 2017, Johannes Weiner wrote: > > > The OOM killer livelock was the motivation for this patch. With that > > ruled out, what's the point of this patch? Try a bit less hard to move > > charges during task migration? > > > > Most

Re: [patch v2] mm, memcg: do not retry precharge charges

2017-01-15 Thread Michal Hocko
On Sat 14-01-17 21:42:48, David Rientjes wrote: > On Sat, 14 Jan 2017, Johannes Weiner wrote: > > > The OOM killer livelock was the motivation for this patch. With that > > ruled out, what's the point of this patch? Try a bit less hard to move > > charges during task migration? > > > > Most

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

2017-01-15 Thread Michal Hocko
On Sat 14-01-17 12:56:32, Leon Romanovsky wrote: [...] > Hi Michal, > > I don't see mlx5_vzalloc in the changed list. Any reason why did you skip it? > > 881 static inline void *mlx5_vzalloc(unsigned long size) > 882 { > 883 void *rtn; > 884 > 885 rtn = kzalloc(size,

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

2017-01-15 Thread Michal Hocko
On Sat 14-01-17 12:56:32, Leon Romanovsky wrote: [...] > Hi Michal, > > I don't see mlx5_vzalloc in the changed list. Any reason why did you skip it? > > 881 static inline void *mlx5_vzalloc(unsigned long size) > 882 { > 883 void *rtn; > 884 > 885 rtn = kzalloc(size,

Re: [PATCH V2] usb: xhci: add support for performing fake doorbell

2017-01-15 Thread Rafał Miłecki
On 21 November 2016 at 16:31, Mathias Nyman wrote: > On 21.11.2016 09:57, Rafał Miłecki wrote: >> >> Hi Mathias, >> >> On 17 October 2016 at 22:30, Rafał Miłecki wrote: >>> >>> From: Rafał Miłecki >>> >>> Broadcom's Northstar

Re: [PATCH V2] usb: xhci: add support for performing fake doorbell

2017-01-15 Thread Rafał Miłecki
On 21 November 2016 at 16:31, Mathias Nyman wrote: > On 21.11.2016 09:57, Rafał Miłecki wrote: >> >> Hi Mathias, >> >> On 17 October 2016 at 22:30, Rafał Miłecki wrote: >>> >>> From: Rafał Miłecki >>> >>> Broadcom's Northstar XHCI controllers seem to need a special start >>> procedure to work

Re: [PATCH] tools: usb usbip - update README USB/IP driver location

2017-01-15 Thread Krzysztof Opasiak
On 01/14/2017 12:38 AM, Shuah Khan wrote: > Update USB/IP driver location in README. > > Signed-off-by: Shuah Khan Reviewed-by: Krzysztof Opasiak Best regards, -- Krzysztof Opasiak Samsung R Institute Poland Samsung Electronics

Re: [PATCH] tools: usb usbip - update README USB/IP driver location

2017-01-15 Thread Krzysztof Opasiak
On 01/14/2017 12:38 AM, Shuah Khan wrote: > Update USB/IP driver location in README. > > Signed-off-by: Shuah Khan Reviewed-by: Krzysztof Opasiak Best regards, -- Krzysztof Opasiak Samsung R Institute Poland Samsung Electronics

[PATCH v8 4/9] iommu/amd: Introduce amd_iommu_get_num_iommus()

2017-01-15 Thread Suravee Suthikulpanit
Introduce amd_iommu_get_num_iommus(), which returns the value of amd_iommus_present, then replaces the direct access to the variable which is now declared as static. This function will also be used by Perf AMD IOMMU driver. Cc: Borislav Petkov Cc: Joerg Roedel

[PATCH v8 3/9] perf/amd/iommu: Misc fix up perf_iommu_read

2017-01-15 Thread Suravee Suthikulpanit
* Fix overflow handling since u64 delta would lose the MSB sign bit. * Remove unnecessary local64_cmpxchg(). * Coding style and make use of GENMASK_ULL macro. Cc: Peter Zijlstra Cc: Borislav Petkov Signed-off-by: Suravee Suthikulpanit

[PATCH v8 4/9] iommu/amd: Introduce amd_iommu_get_num_iommus()

2017-01-15 Thread Suravee Suthikulpanit
Introduce amd_iommu_get_num_iommus(), which returns the value of amd_iommus_present, then replaces the direct access to the variable which is now declared as static. This function will also be used by Perf AMD IOMMU driver. Cc: Borislav Petkov Cc: Joerg Roedel Signed-off-by: Suravee

[PATCH v8 3/9] perf/amd/iommu: Misc fix up perf_iommu_read

2017-01-15 Thread Suravee Suthikulpanit
* Fix overflow handling since u64 delta would lose the MSB sign bit. * Remove unnecessary local64_cmpxchg(). * Coding style and make use of GENMASK_ULL macro. Cc: Peter Zijlstra Cc: Borislav Petkov Signed-off-by: Suravee Suthikulpanit --- arch/x86/events/amd/iommu.c | 23

Re: [PATCH v6 2/3] input: tm2-touchkey: Add touchkey driver support for TM2

2017-01-15 Thread Jaechul Lee
Dear Dmitry Torokhov, On Sat, Jan 14, 2017 at 11:11:10PM -0800, Dmitry Torokhov wrote: > Hi Jaechul, > > On Mon, Jan 09, 2017 at 04:22:14PM +0900, Jaechul Lee wrote: > > +static irqreturn_t tm2_touchkey_irq_handler(int irq, void *devid) > > +{ > > + struct tm2_touchkey_data *touchkey = devid;

[PATCH v8 9/9] perf/amd/iommu: Enable support for multiple IOMMUs

2017-01-15 Thread Suravee Suthikulpanit
From: Suravee Suthikulpanit Add multi-IOMMU support for perf by exposing an AMD IOMMU PMU for each IOMMU found in the system via: /bus/event_source/devices/amd_iommu_x where x is the IOMMU index. This allows users to specify different events to be programed

Re: [PATCH v6 2/3] input: tm2-touchkey: Add touchkey driver support for TM2

2017-01-15 Thread Jaechul Lee
Dear Dmitry Torokhov, On Sat, Jan 14, 2017 at 11:11:10PM -0800, Dmitry Torokhov wrote: > Hi Jaechul, > > On Mon, Jan 09, 2017 at 04:22:14PM +0900, Jaechul Lee wrote: > > +static irqreturn_t tm2_touchkey_irq_handler(int irq, void *devid) > > +{ > > + struct tm2_touchkey_data *touchkey = devid;

[PATCH v8 9/9] perf/amd/iommu: Enable support for multiple IOMMUs

2017-01-15 Thread Suravee Suthikulpanit
From: Suravee Suthikulpanit Add multi-IOMMU support for perf by exposing an AMD IOMMU PMU for each IOMMU found in the system via: /bus/event_source/devices/amd_iommu_x where x is the IOMMU index. This allows users to specify different events to be programed onto performance counters of each

[PATCH v8 7/9] perf/amd/iommu: Check return value when set and get counter value

2017-01-15 Thread Suravee Suthikulpanit
From: Suravee Suthikulpanit In, perf_iommu_start(), we need to check the return value from amd_iommu_set_reg(). In case of failure, we should not enable the PMU. Also, in perf_iommu_read(), we need to check the return value from amd_iommu_get_reg() before using

[PATCH v8 8/9] perf/amd/iommu: Fix sysfs perf attribute groups

2017-01-15 Thread Suravee Suthikulpanit
From: Suravee Suthikulpanit Introduce static amd_iommu_attr_groups to simplify the sysfs attributes initialization code. Cc: Peter Zijlstra Cc: Borislav Petkov Signed-off-by: Suravee Suthikulpanit

Re: [PATCH 1/1] iommu/arm-smmu: Fix for ThunderX erratum #27704

2017-01-15 Thread Tomasz Nowicki
My apologise for not adding 2nd version info of this patch to mail subject. Thanks, Tomasz On 16.01.2017 08:16, Tomasz Nowicki wrote: The goal of erratum #27704 workaround was to make sure that ASIDs and VMIDs are unique across all SMMU instances on affected Cavium systems. Currently, the

[PATCH v8 7/9] perf/amd/iommu: Check return value when set and get counter value

2017-01-15 Thread Suravee Suthikulpanit
From: Suravee Suthikulpanit In, perf_iommu_start(), we need to check the return value from amd_iommu_set_reg(). In case of failure, we should not enable the PMU. Also, in perf_iommu_read(), we need to check the return value from amd_iommu_get_reg() before using the value. Cc: Peter Zijlstra

[PATCH v8 8/9] perf/amd/iommu: Fix sysfs perf attribute groups

2017-01-15 Thread Suravee Suthikulpanit
From: Suravee Suthikulpanit Introduce static amd_iommu_attr_groups to simplify the sysfs attributes initialization code. Cc: Peter Zijlstra Cc: Borislav Petkov Signed-off-by: Suravee Suthikulpanit --- arch/x86/events/amd/iommu.c | 85 - 1 file

Re: [PATCH 1/1] iommu/arm-smmu: Fix for ThunderX erratum #27704

2017-01-15 Thread Tomasz Nowicki
My apologise for not adding 2nd version info of this patch to mail subject. Thanks, Tomasz On 16.01.2017 08:16, Tomasz Nowicki wrote: The goal of erratum #27704 workaround was to make sure that ASIDs and VMIDs are unique across all SMMU instances on affected Cavium systems. Currently, the

[PATCH v8 2/9] perf/amd/iommu: Clean up perf_iommu_enable_event

2017-01-15 Thread Suravee Suthikulpanit
From: Suravee Suthikulpanit * Clean up various bitwise operations in perf_iommu_enable_event * Make use macros BIT(x) This should not affect logic and functionality. Cc: Peter Zijlstra Cc: Borislav Petkov Signed-off-by:

[PATCH v8 2/9] perf/amd/iommu: Clean up perf_iommu_enable_event

2017-01-15 Thread Suravee Suthikulpanit
From: Suravee Suthikulpanit * Clean up various bitwise operations in perf_iommu_enable_event * Make use macros BIT(x) This should not affect logic and functionality. Cc: Peter Zijlstra Cc: Borislav Petkov Signed-off-by: Suravee Suthikulpanit --- arch/x86/events/amd/iommu.c | 18

[PATCH v8 5/9] perf/amd/iommu: Modify functions to query max banks and counters

2017-01-15 Thread Suravee Suthikulpanit
Currently, amd_iommu_pc_get_max_[banks|counters]() use end-point device ID to locate an IOMMU and check the reported max banks/counters. The logic assumes that the IOMMU_BASE_DEVID belongs to the first IOMMU, and uses it to acquire a reference to the first IOMMU, which does not work on certain

[PATCH v8 6/9] perf/amd/iommu: Modify amd_iommu_pc_get_set_reg_val() API to allow specifying IOMMU index

2017-01-15 Thread Suravee Suthikulpanit
From: Suravee Suthikulpanit The current amd_iommu_pc_get_set_reg_val() cannot support multiple IOMMUs It is also confusing since it is trying to support set and get in one function. So break it down to amd_iommu_pc_[get|set]_reg(), and modifies them to allow

[PATCH v8 5/9] perf/amd/iommu: Modify functions to query max banks and counters

2017-01-15 Thread Suravee Suthikulpanit
Currently, amd_iommu_pc_get_max_[banks|counters]() use end-point device ID to locate an IOMMU and check the reported max banks/counters. The logic assumes that the IOMMU_BASE_DEVID belongs to the first IOMMU, and uses it to acquire a reference to the first IOMMU, which does not work on certain

[PATCH v8 6/9] perf/amd/iommu: Modify amd_iommu_pc_get_set_reg_val() API to allow specifying IOMMU index

2017-01-15 Thread Suravee Suthikulpanit
From: Suravee Suthikulpanit The current amd_iommu_pc_get_set_reg_val() cannot support multiple IOMMUs It is also confusing since it is trying to support set and get in one function. So break it down to amd_iommu_pc_[get|set]_reg(), and modifies them to allow callers to specify IOMMU index. This

[PATCH v8 1/9] perf/amd/iommu: Declare pr_fmt and remove unnecessary pr_debug

2017-01-15 Thread Suravee Suthikulpanit
Declare pr_fmt for perf/amd_iommu and remove unnecessary pr_debug. Also check return value when _init_events_attrs fails. Cc: Peter Zijlstra Cc: Borislav Petkov Signed-off-by: Suravee Suthikulpanit ---

[PATCH v8 1/9] perf/amd/iommu: Declare pr_fmt and remove unnecessary pr_debug

2017-01-15 Thread Suravee Suthikulpanit
Declare pr_fmt for perf/amd_iommu and remove unnecessary pr_debug. Also check return value when _init_events_attrs fails. Cc: Peter Zijlstra Cc: Borislav Petkov Signed-off-by: Suravee Suthikulpanit --- arch/x86/events/amd/iommu.c | 20 1 file changed, 8 insertions(+), 12

[PATCH v8 0/9] perf/amd/iommu: Enable multi-IOMMU support

2017-01-15 Thread Suravee Suthikulpanit
From: Suravee Suthikulpanit This patch series modifies the existing IOMMU and Perf drivers to support systems with multiple IOMMUs by allocating an amd_iommu PMU per IOMMU instance. This allows users to specify performance events and filters separately for each

[PATCH v8 0/9] perf/amd/iommu: Enable multi-IOMMU support

2017-01-15 Thread Suravee Suthikulpanit
From: Suravee Suthikulpanit This patch series modifies the existing IOMMU and Perf drivers to support systems with multiple IOMMUs by allocating an amd_iommu PMU per IOMMU instance. This allows users to specify performance events and filters separately for each IOMMU. This has been tested on

[PATCH 1/1] iommu/arm-smmu: Fix for ThunderX erratum #27704

2017-01-15 Thread Tomasz Nowicki
The goal of erratum #27704 workaround was to make sure that ASIDs and VMIDs are unique across all SMMU instances on affected Cavium systems. Currently, the workaround code partitions ASIDs and VMIDs by increasing global cavium_smmu_context_count which in turn becomes the base ASID and VMID value

[PATCH 1/1] iommu/arm-smmu: Fix for ThunderX erratum #27704

2017-01-15 Thread Tomasz Nowicki
The goal of erratum #27704 workaround was to make sure that ASIDs and VMIDs are unique across all SMMU instances on affected Cavium systems. Currently, the workaround code partitions ASIDs and VMIDs by increasing global cavium_smmu_context_count which in turn becomes the base ASID and VMID value

Re: sctp: kernel memory overwrite attempt detected in sctp_getsockopt_assoc_stats

2017-01-15 Thread Dmitry Vyukov
On Sun, Jan 15, 2017 at 9:35 PM, Neil Horman wrote: > On Sun, Jan 15, 2017 at 06:29:59PM +0100, Dmitry Vyukov wrote: >> Hello, >> >> I've enabled CONFIG_HARDENED_USERCOPY_PAGESPAN on syzkaller fuzzer and >> now I am seeing lots of: >> > If I'm not mistaken, its because

Re: sctp: kernel memory overwrite attempt detected in sctp_getsockopt_assoc_stats

2017-01-15 Thread Dmitry Vyukov
On Sun, Jan 15, 2017 at 9:35 PM, Neil Horman wrote: > On Sun, Jan 15, 2017 at 06:29:59PM +0100, Dmitry Vyukov wrote: >> Hello, >> >> I've enabled CONFIG_HARDENED_USERCOPY_PAGESPAN on syzkaller fuzzer and >> now I am seeing lots of: >> > If I'm not mistaken, its because thats specifically what

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

2017-01-15 Thread Shawn Guo
On Sat, Jan 14, 2017 at 03:05:28PM +0800, Baoyou Xie wrote: > This patch adds dt-binding documentation for zx2967 family > reset controller. > > Signed-off-by: Baoyou Xie Reviewed-by: Shawn Guo

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

2017-01-15 Thread Shawn Guo
On Sat, Jan 14, 2017 at 03:05:28PM +0800, Baoyou Xie wrote: > This patch adds dt-binding documentation for zx2967 family > reset controller. > > Signed-off-by: Baoyou Xie Reviewed-by: Shawn Guo

[PATCH V2] Staging: media: bcm2048: style fix - bare use of unsigned

2017-01-15 Thread Derek Robson
Changed macro to not pass signedness and size as seprate fields. This is to improve code readablity. Signed-off-by: Derek Robson --- version #1 broke the build because I missunderstood the output of checkpatch. drivers/staging/media/bcm2048/radio-bcm2048.c | 48

[PATCH V2] Staging: media: bcm2048: style fix - bare use of unsigned

2017-01-15 Thread Derek Robson
Changed macro to not pass signedness and size as seprate fields. This is to improve code readablity. Signed-off-by: Derek Robson --- version #1 broke the build because I missunderstood the output of checkpatch. drivers/staging/media/bcm2048/radio-bcm2048.c | 48 +-- 1

[PATCH] slab: add a check for the first kmem_cache not to be destroyed

2017-01-15 Thread Kyunghwan Kwon
The first kmem_cache created at booting up is supposed neither mergeable nor destroyable but was possible to destroy. So prevent it. Signed-off-by: Kyunghwan Kwon --- mm/slab_common.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/mm/slab_common.c

Re: [HMM v16 04/15] mm/ZONE_DEVICE/unaddressable: add support for un-addressable device memory v2

2017-01-15 Thread Dan Williams
On Thu, Jan 12, 2017 at 8:30 AM, Jérôme Glisse wrote: > This add support for un-addressable device memory. Such memory is hotpluged > only so we can have struct page but we should never map them as such memory > can not be accessed by CPU. For that reason it uses a special

[PATCH] slab: add a check for the first kmem_cache not to be destroyed

2017-01-15 Thread Kyunghwan Kwon
The first kmem_cache created at booting up is supposed neither mergeable nor destroyable but was possible to destroy. So prevent it. Signed-off-by: Kyunghwan Kwon --- mm/slab_common.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/mm/slab_common.c b/mm/slab_common.c index

Re: [HMM v16 04/15] mm/ZONE_DEVICE/unaddressable: add support for un-addressable device memory v2

2017-01-15 Thread Dan Williams
On Thu, Jan 12, 2017 at 8:30 AM, Jérôme Glisse wrote: > This add support for un-addressable device memory. Such memory is hotpluged > only so we can have struct page but we should never map them as such memory > can not be accessed by CPU. For that reason it uses a special swap entry for > CPU

Re: [PATCH v4 3/3] thermal: zx2967: add thermal driver for ZTE's zx2967 family

2017-01-15 Thread Shawn Guo
On Fri, Jan 13, 2017 at 06:46:58PM +0800, Baoyou Xie wrote: > This patch adds thermal driver for ZTE's zx2967 family. > > Signed-off-by: Baoyou Xie Reviewed-by: Shawn Guo

Re: [PATCH v4 3/3] thermal: zx2967: add thermal driver for ZTE's zx2967 family

2017-01-15 Thread Shawn Guo
On Fri, Jan 13, 2017 at 06:46:58PM +0800, Baoyou Xie wrote: > This patch adds thermal driver for ZTE's zx2967 family. > > Signed-off-by: Baoyou Xie Reviewed-by: Shawn Guo

Re: [PATCH v2 2/2] ocfs2: fix deadlock issue when taking inode lock at vfs entry points

2017-01-15 Thread Junxiao Bi
On 01/16/2017 02:42 PM, Eric Ren wrote: > Commit 743b5f1434f5 ("ocfs2: take inode lock in ocfs2_iop_set/get_acl()") > results in a deadlock, as the author "Tariq Saeed" realized shortly > after the patch was merged. The discussion happened here >

Re: [PATCH v2 2/2] ocfs2: fix deadlock issue when taking inode lock at vfs entry points

2017-01-15 Thread Junxiao Bi
On 01/16/2017 02:42 PM, Eric Ren wrote: > Commit 743b5f1434f5 ("ocfs2: take inode lock in ocfs2_iop_set/get_acl()") > results in a deadlock, as the author "Tariq Saeed" realized shortly > after the patch was merged. The discussion happened here >

Re: [PATCH tip/core/rcu 2/3] srcu: Force full grace-period ordering

2017-01-15 Thread Ingo Molnar
* Paul E. McKenney wrote: > On Sun, Jan 15, 2017 at 10:40:58AM +0100, Ingo Molnar wrote: > > > > * Paul E. McKenney wrote: > > > > > > [sounds of rummaging around in the Git tree] > > > > > > > > I found this commit of yours from

Re: [PATCH V2 6/6] gpio: davinci: Remove redundant macros

2017-01-15 Thread Keerthy
Linus, On Friday 13 January 2017 09:50 AM, Keerthy wrote: Some of the macros were needed as per old driver design. With the current implementation they are unwanted. Hence remove them. Seems like Macros are being used in: arch/arm/mach-davinci/board-neuros-osd2.c So this patch can be dropped

Re: [PATCH tip/core/rcu 2/3] srcu: Force full grace-period ordering

2017-01-15 Thread Ingo Molnar
* Paul E. McKenney wrote: > On Sun, Jan 15, 2017 at 10:40:58AM +0100, Ingo Molnar wrote: > > > > * Paul E. McKenney wrote: > > > > > > [sounds of rummaging around in the Git tree] > > > > > > > > I found this commit of yours from ancient history (more than a year > > > > ago!): > > > > >

Re: [PATCH V2 6/6] gpio: davinci: Remove redundant macros

2017-01-15 Thread Keerthy
Linus, On Friday 13 January 2017 09:50 AM, Keerthy wrote: Some of the macros were needed as per old driver design. With the current implementation they are unwanted. Hence remove them. Seems like Macros are being used in: arch/arm/mach-davinci/board-neuros-osd2.c So this patch can be dropped

Re: [GIT RFC PULL rcu/urgent] Make RCU synchronous grace periods work throughout boot

2017-01-15 Thread Ingo Molnar
* Paul E. McKenney wrote: > Hello, Ingo, > > This series contains a pair of commits that permit RCU synchronous grace > periods (synchronize_rcu() and friends) to work correctly throughout boot. > This eliminates the current "dead time" starting when the scheduler

Re: [GIT RFC PULL rcu/urgent] Make RCU synchronous grace periods work throughout boot

2017-01-15 Thread Ingo Molnar
* Paul E. McKenney wrote: > Hello, Ingo, > > This series contains a pair of commits that permit RCU synchronous grace > periods (synchronize_rcu() and friends) to work correctly throughout boot. > This eliminates the current "dead time" starting when the scheduler spawns > its first taks and

Re: [PATCH] pcie: ti: Provide patch to force GEN1 PCIe operation

2017-01-15 Thread Lukasz Majewski
Hi Kishon, > Hi, > > On Sunday 15 January 2017 06:49 PM, Lukasz Majewski wrote: > > Some devices (due to e.g. bad PCIe signal integrity) require to run > > with forced GEN1 speed on PCIe bus. > > > > This patch changes the speed explicitly on dra7 based devices when > > proper device tree

Re: [PATCH] pcie: ti: Provide patch to force GEN1 PCIe operation

2017-01-15 Thread Lukasz Majewski
Hi Kishon, > Hi, > > On Sunday 15 January 2017 06:49 PM, Lukasz Majewski wrote: > > Some devices (due to e.g. bad PCIe signal integrity) require to run > > with forced GEN1 speed on PCIe bus. > > > > This patch changes the speed explicitly on dra7 based devices when > > proper device tree

[PATCH v1] edac: i82975x_edac :- Handle return NULL error from ioremap_nocache

2017-01-15 Thread Arvind Yadav
Here, If ioremap_nocache will fail. It will return NULL. Kernel can run into a NULL-pointer dereference. This error check will avoid NULL pointer dereference. Signed-off-by: Arvind Yadav --- drivers/edac/i82975x_edac.c | 4 1 file changed, 4 insertions(+) diff

[PATCH v1] edac: i82975x_edac :- Handle return NULL error from ioremap_nocache

2017-01-15 Thread Arvind Yadav
Here, If ioremap_nocache will fail. It will return NULL. Kernel can run into a NULL-pointer dereference. This error check will avoid NULL pointer dereference. Signed-off-by: Arvind Yadav --- drivers/edac/i82975x_edac.c | 4 1 file changed, 4 insertions(+) diff --git

Re: [PATCH v2 4/4] mfd: max77686: Remove I2C device ID table

2017-01-15 Thread Chanwoo Choi
Hi, I think that this patch better to squash with patch3. After applying the patch3, this driver doesn't use the max77686_i2c_id table. On 2017년 01월 13일 22:34, Javier Martinez Canillas wrote: > The driver is only used in DT platforms so there's no need to > have an i2c_device_id table. > >

Re: [PATCH 0/9] Serial slave device bus

2017-01-15 Thread H. Nikolaus Schaller
Hi Rob, > Am 13.01.2017 um 15:48 schrieb Rob Herring : > > On Fri, Jan 13, 2017 at 5:22 AM, H. Nikolaus Schaller > wrote: >> Hi Rob, >> was it intentional to answer privately only? > > Damn gmail. Added everyone back. No problem. Happens to everyone every

Re: [PATCH v2 4/4] mfd: max77686: Remove I2C device ID table

2017-01-15 Thread Chanwoo Choi
Hi, I think that this patch better to squash with patch3. After applying the patch3, this driver doesn't use the max77686_i2c_id table. On 2017년 01월 13일 22:34, Javier Martinez Canillas wrote: > The driver is only used in DT platforms so there's no need to > have an i2c_device_id table. > >

Re: [PATCH 0/9] Serial slave device bus

2017-01-15 Thread H. Nikolaus Schaller
Hi Rob, > Am 13.01.2017 um 15:48 schrieb Rob Herring : > > On Fri, Jan 13, 2017 at 5:22 AM, H. Nikolaus Schaller > wrote: >> Hi Rob, >> was it intentional to answer privately only? > > Damn gmail. Added everyone back. No problem. Happens to everyone every now and then. > >>> Am 12.01.2017

Re: [PATCH] usb: host: xhci: plat: check hcc_params after add hcd

2017-01-15 Thread wlf
Hi Roger, 在 2017年01月13日 19:02, Roger Quadros 写道: Hi, On 13/01/17 05:18, William Wu wrote: From: William wu The commit 4ac53087d6d4 ("usb: xhci: plat: Create both HCDs before adding them") move add hcd to the end of probe, this cause hcc_params uninitiated, because

Re: [PATCH] usb: host: xhci: plat: check hcc_params after add hcd

2017-01-15 Thread wlf
Hi Roger, 在 2017年01月13日 19:02, Roger Quadros 写道: Hi, On 13/01/17 05:18, William Wu wrote: From: William wu The commit 4ac53087d6d4 ("usb: xhci: plat: Create both HCDs before adding them") move add hcd to the end of probe, this cause hcc_params uninitiated, because xHCI driver sets

[PATCH v2 0/2] fix deadlock caused by recursive cluster locking

2017-01-15 Thread Eric Ren
This is a formal patch set v2 to solve the deadlock issue on which I previously started a RFC (draft patch), and the discussion happened here: [https://oss.oracle.com/pipermail/ocfs2-devel/2016-October/012455.html] Compared to the previous draft patch, this one is much simple and neat. It neither

[PATCH v2 0/2] fix deadlock caused by recursive cluster locking

2017-01-15 Thread Eric Ren
This is a formal patch set v2 to solve the deadlock issue on which I previously started a RFC (draft patch), and the discussion happened here: [https://oss.oracle.com/pipermail/ocfs2-devel/2016-October/012455.html] Compared to the previous draft patch, this one is much simple and neat. It neither

[PATCH v2 1/2] ocfs2/dlmglue: prepare tracking logic to avoid recursive cluster lock

2017-01-15 Thread Eric Ren
We are in the situation that we have to avoid recursive cluster locking, but there is no way to check if a cluster lock has been taken by a precess already. Mostly, we can avoid recursive locking by writing code carefully. However, we found that it's very hard to handle the routines that are

[PATCH v2 2/2] ocfs2: fix deadlock issue when taking inode lock at vfs entry points

2017-01-15 Thread Eric Ren
Commit 743b5f1434f5 ("ocfs2: take inode lock in ocfs2_iop_set/get_acl()") results in a deadlock, as the author "Tariq Saeed" realized shortly after the patch was merged. The discussion happened here (https://oss.oracle.com/pipermail/ocfs2-devel/2015-September/011085.html). The reason why taking

[PATCH v2 1/2] ocfs2/dlmglue: prepare tracking logic to avoid recursive cluster lock

2017-01-15 Thread Eric Ren
We are in the situation that we have to avoid recursive cluster locking, but there is no way to check if a cluster lock has been taken by a precess already. Mostly, we can avoid recursive locking by writing code carefully. However, we found that it's very hard to handle the routines that are

[PATCH v2 2/2] ocfs2: fix deadlock issue when taking inode lock at vfs entry points

2017-01-15 Thread Eric Ren
Commit 743b5f1434f5 ("ocfs2: take inode lock in ocfs2_iop_set/get_acl()") results in a deadlock, as the author "Tariq Saeed" realized shortly after the patch was merged. The discussion happened here (https://oss.oracle.com/pipermail/ocfs2-devel/2015-September/011085.html). The reason why taking

Re: [PATCH] pcie: ti: Provide patch to force GEN1 PCIe operation

2017-01-15 Thread Kishon Vijay Abraham I
Hi, On Sunday 15 January 2017 06:49 PM, Lukasz Majewski wrote: > Some devices (due to e.g. bad PCIe signal integrity) require to run > with forced GEN1 speed on PCIe bus. > > This patch changes the speed explicitly on dra7 based devices when > proper device tree attribute is defined for the PCIe

Re: [PATCH] pcie: ti: Provide patch to force GEN1 PCIe operation

2017-01-15 Thread Kishon Vijay Abraham I
Hi, On Sunday 15 January 2017 06:49 PM, Lukasz Majewski wrote: > Some devices (due to e.g. bad PCIe signal integrity) require to run > with forced GEN1 speed on PCIe bus. > > This patch changes the speed explicitly on dra7 based devices when > proper device tree attribute is defined for the PCIe

Re: [PATCH v2 3/4] mfd: max77686: Use the struct i2c_driver .probe_new instead of .probe

2017-01-15 Thread Chanwoo Choi
Hi, On 2017년 01월 13일 22:34, Javier Martinez Canillas wrote: > If a driver is only used in DT platforms, there's no need to get the > i2c_device_id as an argument of the probe function. Since this data > can be get from the matching of_device_id. > > There's a temporary .probe_new field in struct

Re: [PATCH v2 3/4] mfd: max77686: Use the struct i2c_driver .probe_new instead of .probe

2017-01-15 Thread Chanwoo Choi
Hi, On 2017년 01월 13일 22:34, Javier Martinez Canillas wrote: > If a driver is only used in DT platforms, there's no need to get the > i2c_device_id as an argument of the probe function. Since this data > can be get from the matching of_device_id. > > There's a temporary .probe_new field in struct

Re: [PATCH v2 2/4] mfd: max77686: Use of_device_get_match_data() helper

2017-01-15 Thread Chanwoo Choi
Hi, On 2017년 01월 13일 22:34, Javier Martinez Canillas wrote: > Use the generic helper to get the matched of_device_id .data, instead of > open coding it. > > The driver was checking if matching the OF node with the driver's OF table > was failing, but this doesn't make too much sense since this

Re: [PATCH v2 2/4] mfd: max77686: Use of_device_get_match_data() helper

2017-01-15 Thread Chanwoo Choi
Hi, On 2017년 01월 13일 22:34, Javier Martinez Canillas wrote: > Use the generic helper to get the matched of_device_id .data, instead of > open coding it. > > The driver was checking if matching the OF node with the driver's OF table > was failing, but this doesn't make too much sense since this

Re: [PATCH v9 0/8] drivers: touchscreen: tsc2007 and ads7846/tsc2046 improvements (use common touchscreen bindings, pre-calibration, spi fix and provide iio raw values)

2017-01-15 Thread H. Nikolaus Schaller
ping > Am 28.12.2016 um 15:53 schrieb H. Nikolaus Schaller : > > Changes V9: > * added explicit CONFIG for TSC2007_IIO and simplified Makefile (suggested by > Dmitry Torokhov ) > * make the tsc2007 iio patch the last one in this sequence > >

Re: [PATCH v9 0/8] drivers: touchscreen: tsc2007 and ads7846/tsc2046 improvements (use common touchscreen bindings, pre-calibration, spi fix and provide iio raw values)

2017-01-15 Thread H. Nikolaus Schaller
ping > Am 28.12.2016 um 15:53 schrieb H. Nikolaus Schaller : > > Changes V9: > * added explicit CONFIG for TSC2007_IIO and simplified Makefile (suggested by > Dmitry Torokhov ) > * make the tsc2007 iio patch the last one in this sequence > > 2016-11-22 15:02:42: Changes V8: > * fix compilation

[PATCH V3 4/5] PCI: exynos: Use the bitops API to operate the bit shifting

2017-01-15 Thread Jaehoon Chung
Just use the bitops api to operate the bit. Signed-off-by: Jaehoon Chung Reviewed-by: Pankaj Dubey Acked-by: Krzysztof Kozlowski --- Changelog on V3: - None Changelog on V2: - None drivers/pci/host/pci-exynos.c | 24

[PATCH V3 4/5] PCI: exynos: Use the bitops API to operate the bit shifting

2017-01-15 Thread Jaehoon Chung
Just use the bitops api to operate the bit. Signed-off-by: Jaehoon Chung Reviewed-by: Pankaj Dubey Acked-by: Krzysztof Kozlowski --- Changelog on V3: - None Changelog on V2: - None drivers/pci/host/pci-exynos.c | 24 1 file changed, 12 insertions(+), 12 deletions(-)

[PATCH V3 3/5] PCI: exynos: Remove the unnecessary variables

2017-01-15 Thread Jaehoon Chung
Remove the unnecessary variables(elbi/phy/block_base). It needs one resource structure for assigning each resource. So it replaces with one 'res' variable. Signed-off-by: Jaehoon Chung Reviewed-by: Pankaj Dubey Acked-by: Krzysztof Kozlowski

[PATCH V3 0/5] PCI: exynos: cleans the minor things

2017-01-15 Thread Jaehoon Chung
Current pci-exynos.c is used for only EXYNOS5440. It's too complex to support the other Exynos SoCs. Before supporting the other Exynos SoCs, it needs to clean the codes. Changelog on V3: - Splits "PCI: exynos: replace to one register accessor from each accessors" Changelog on V2: - Changes the

[PATCH V3 3/5] PCI: exynos: Remove the unnecessary variables

2017-01-15 Thread Jaehoon Chung
Remove the unnecessary variables(elbi/phy/block_base). It needs one resource structure for assigning each resource. So it replaces with one 'res' variable. Signed-off-by: Jaehoon Chung Reviewed-by: Pankaj Dubey Acked-by: Krzysztof Kozlowski --- Changelog on V3: - None Changelog on V2: - None

[PATCH V3 0/5] PCI: exynos: cleans the minor things

2017-01-15 Thread Jaehoon Chung
Current pci-exynos.c is used for only EXYNOS5440. It's too complex to support the other Exynos SoCs. Before supporting the other Exynos SoCs, it needs to clean the codes. Changelog on V3: - Splits "PCI: exynos: replace to one register accessor from each accessors" Changelog on V2: - Changes the

  1   2   3   4   5   6   7   >