Re: Please review arch/x86/kernel/pvclock.c to fix Docker/Mono crashes in new Kernels

There is something odd being reported in Ubuntu. There's a Mono SIGSEGV that was bisected to Andy's commit 1ddf0b1b11aa ("x86, vdso: Use asm volatile in __getcpu"), and then reported to be fixed with commits 80f7fdb1c7f0 ("x86: vdso: fix pvclock races with task migration") 0a4e6be9ca17

Re: Please review arch/x86/kernel/pvclock.c to fix Docker/Mono crashes in new Kernels

There is something odd being reported in Ubuntu. There's a Mono SIGSEGV that was bisected to Andy's commit 1ddf0b1b11aa ("x86, vdso: Use asm volatile in __getcpu"), and then reported to be fixed with commits 80f7fdb1c7f0 ("x86: vdso: fix pvclock races with task migration") 0a4e6be9ca17

Re: [PATCH] net/hsr: Use setup_timer and mod_timer.

From: Muhammad Falak R Wani Date: Sun, 15 May 2016 19:37:44 +0530 > The function setup_timer combines the initialization of a timer with the > initialization of the timer's function and data fields. The mulitiline > code for timer initialization is now replaced with

Re: [PATCH] net/hsr: Use setup_timer and mod_timer.

From: Muhammad Falak R Wani Date: Sun, 15 May 2016 19:37:44 +0530 > The function setup_timer combines the initialization of a timer with the > initialization of the timer's function and data fields. The mulitiline > code for timer initialization is now replaced with function setup_timer. > >

Re: [PATCH] phy dp83867: depend on CONFIG_OF_MDIO

On 16.05.16 14:44, Andrew Lunn wrote: > On Mon, May 16, 2016 at 01:28:15PM +0200, Alexander Graf wrote: >> The DP83867 phy driver doesn't actually work when CONFIG_OF_MDIO isn't >> enabled. >> It simply passes the device tree test, but leaves all internal configuration >> initialized at 0. Then

Re: [PATCH] phy dp83867: depend on CONFIG_OF_MDIO

On 16.05.16 14:44, Andrew Lunn wrote: > On Mon, May 16, 2016 at 01:28:15PM +0200, Alexander Graf wrote: >> The DP83867 phy driver doesn't actually work when CONFIG_OF_MDIO isn't >> enabled. >> It simply passes the device tree test, but leaves all internal configuration >> initialized at 0. Then

Re: [PATCH] phy dp83867: depend on CONFIG_OF_MDIO

Hi Dan, On 16.05.16 15:38, Dan Murphy wrote: > Alexander > > On 05/16/2016 06:28 AM, Alexander Graf wrote: >> The DP83867 phy driver doesn't actually work when CONFIG_OF_MDIO isn't >> enabled. >> It simply passes the device tree test, but leaves all internal configuration >> initialized at 0.

Re: [PATCH] phy dp83867: depend on CONFIG_OF_MDIO

Hi Dan, On 16.05.16 15:38, Dan Murphy wrote: > Alexander > > On 05/16/2016 06:28 AM, Alexander Graf wrote: >> The DP83867 phy driver doesn't actually work when CONFIG_OF_MDIO isn't >> enabled. >> It simply passes the device tree test, but leaves all internal configuration >> initialized at 0.

Re: [v4.6-rc7-183-g1410b74e4061]

On Mon, May 16, 2016 at 07:42:35PM +0200, Sedat Dilek wrote: > Unfortunately, I could not reproduce this again with none of my 183-kernels. > When I first hit a "chain_key collision" issue, it was hard to redproduce, so. > Any idea, how I can "force" this? Nope; I wish I knew, that'd be so much

Re: [v4.6-rc7-183-g1410b74e4061]

On Mon, May 16, 2016 at 07:42:35PM +0200, Sedat Dilek wrote: > Unfortunately, I could not reproduce this again with none of my 183-kernels. > When I first hit a "chain_key collision" issue, it was hard to redproduce, so. > Any idea, how I can "force" this? Nope; I wish I knew, that'd be so much

Re: [PATCH] Input: Change BTN_TOOL_FINGER flag when hover event trigger

Hi Kt, On Mon, May 16, 2016 at 07:27:25PM +0800, 廖崇榮 wrote: > > Only ABS_DISTANCE is not enough for upper OS to distingiush hover event be > triggered from object from faraway to and close touchpad surface or from > object prepare to leave the touchpad surface. Add BTN_TOOL_FINGER flag to > help

Re: [PATCH] Input: Change BTN_TOOL_FINGER flag when hover event trigger

Hi Kt, On Mon, May 16, 2016 at 07:27:25PM +0800, 廖崇榮 wrote: > > Only ABS_DISTANCE is not enough for upper OS to distingiush hover event be > triggered from object from faraway to and close touchpad surface or from > object prepare to leave the touchpad surface. Add BTN_TOOL_FINGER flag to > help

Re: [PATCH v2] locking/rwsem: Add reader-owned state to the owner field

On Mon, May 16, 2016 at 07:17:42AM -0700, Peter Hurley wrote: > >> Correct; which is why we should always use {READ,WRITE}_ONCE() for > >> anything that is used locklessly. > > > > Completely agreed. Improve readability of code by flagging lockless > > shared-memory accesses, help checkers

Re: [PATCH v2] locking/rwsem: Add reader-owned state to the owner field

On Mon, May 16, 2016 at 07:17:42AM -0700, Peter Hurley wrote: > >> Correct; which is why we should always use {READ,WRITE}_ONCE() for > >> anything that is used locklessly. > > > > Completely agreed. Improve readability of code by flagging lockless > > shared-memory accesses, help checkers

[GIT PULL] arm64: perf updates for 4.7

Hi Linus, Please pull the following arm64 perf updates for 4.7. The main addition here is support for Broadcom's Vulcan core using the architected ID registers for discovering supported events. Cheers, Will --->8 The following changes since commit bf16200689118d19de1b8d2a3c314fc21f5dc7bb:

[GIT PULL] arm64: perf updates for 4.7

Hi Linus, Please pull the following arm64 perf updates for 4.7. The main addition here is support for Broadcom's Vulcan core using the architected ID registers for discovering supported events. Cheers, Will --->8 The following changes since commit bf16200689118d19de1b8d2a3c314fc21f5dc7bb:

[GIT PULL] arm64: updates for 4.7

Hi Linus, Here's the arm64 queue for 4.7 -- the highlights are detailed in the tag. There are a few changes here outside of arch/arm64/ as a result of dependencies (all acked by the relevant maintainers), but these have generated some conflicts in linux-next: 1. KVM: There is a conflict in

[GIT PULL] arm64: updates for 4.7

Hi Linus, Here's the arm64 queue for 4.7 -- the highlights are detailed in the tag. There are a few changes here outside of arch/arm64/ as a result of dependencies (all acked by the relevant maintainers), but these have generated some conflicts in linux-next: 1. KVM: There is a conflict in

Re: [PATCH net] net: dsa: mv88e6xxx: remove bridge work

From: Vivien Didelot Date: Fri, 13 May 2016 21:28:28 -0400 > Hi David, > > Vivien Didelot writes: > >> Now that the bridge code defers the switchdev port state setting, there >> is no need to defer the port STP state

Re: [PATCH net] net: dsa: mv88e6xxx: remove bridge work

From: Vivien Didelot Date: Fri, 13 May 2016 21:28:28 -0400 > Hi David, > > Vivien Didelot writes: > >> Now that the bridge code defers the switchdev port state setting, there >> is no need to defer the port STP state change within the mv88e6xxx code. >> Thus get rid of the driver's bridge

Re: CQ and RDMA READ/WRITE APIs

On Mon, May 16, 2016 at 7:51 AM, Doug Ledford wrote: > > The linux kernel as a whole is, but individual files still retain their > separate copyright, they don't loose it just because they are shipped as > part of the larger kernel. .. they do lose it if they have GPL'd code

Re: CQ and RDMA READ/WRITE APIs

On Mon, May 16, 2016 at 7:51 AM, Doug Ledford wrote: > > The linux kernel as a whole is, but individual files still retain their > separate copyright, they don't loose it just because they are shipped as > part of the larger kernel. .. they do lose it if they have GPL'd code merged into them.

Re: [PATCH] net: qrtr: fix build problems

From: Arnd Bergmann Date: Fri, 13 May 2016 15:09:58 +0200 > Having multiple loadable modules with the same name cannot work > with modprobe, and having both net/qrtr/smd.ko and drivers/soc/qcom/smd.ko > results in a (somewhat cryptic) build error: > > ERROR:

Re: [PATCH] net: qrtr: fix build problems

From: Arnd Bergmann Date: Fri, 13 May 2016 15:09:58 +0200 > Having multiple loadable modules with the same name cannot work > with modprobe, and having both net/qrtr/smd.ko and drivers/soc/qcom/smd.ko > results in a (somewhat cryptic) build error: > > ERROR: "qcom_smd_driver_unregister"

RE: [PATCH] dell_rbu: Don't fallback to userhelper when loading firmware

> -Original Message- > From: Laura Abbott [mailto:labb...@redhat.com] > Sent: Monday, May 16, 2016 12:12 PM > To: Limonciello, Mario ; > ming@canonical.com > Cc: LKML > Subject: Re: [PATCH] dell_rbu: Don't fallback to

RE: [PATCH] dell_rbu: Don't fallback to userhelper when loading firmware

> -Original Message- > From: Laura Abbott [mailto:labb...@redhat.com] > Sent: Monday, May 16, 2016 12:12 PM > To: Limonciello, Mario ; > ming@canonical.com > Cc: LKML > Subject: Re: [PATCH] dell_rbu: Don't fallback to userhelper when loading > firmware > > On 05/16/2016 08:41 AM,

Re: [v4.6-rc7-183-g1410b74e4061]

On 5/16/16, Ingo Molnar wrote: > > * Sedat Dilek wrote: > >> Hi, >> >> as Linux v4.6 is very near, I decided to write this bug report (only >> drunk one coffee). >> >> First, I am not absolutely sure if this is a real issue as... >> #1: This is only a

Re: [v4.6-rc7-183-g1410b74e4061]

On 5/16/16, Ingo Molnar wrote: > > * Sedat Dilek wrote: > >> Hi, >> >> as Linux v4.6 is very near, I decided to write this bug report (only >> drunk one coffee). >> >> First, I am not absolutely sure if this is a real issue as... >> #1: This is only a (lockdep) warning. >> #2: I have not a

Re: [PATCH 0/2] net: pxa168_eth: improve performance

From: Jisheng Zhang Date: Fri, 13 May 2016 19:57:28 +0800 > This series is to improve the pxa168_eth driver performance by using > {readl|writel}_relaxed or appropriate memory barriers. Applied.

Re: [PATCH 0/2] net: pxa168_eth: improve performance

From: Jisheng Zhang Date: Fri, 13 May 2016 19:57:28 +0800 > This series is to improve the pxa168_eth driver performance by using > {readl|writel}_relaxed or appropriate memory barriers. Applied.

Re: [3.19.y-ckt stable] Linux 3.19.8-ckt21

On 16.05.2016 18:58, Kamal Mostafa wrote: > > Queued up for 3.19-stable. Thanks very much for the backport, Philip. > > -Kamal > Thx. Due this fact I also found another issue with it. Somehow some other patch is needed to get it compiled with gcc 6.1 series.

Re: [3.19.y-ckt stable] Linux 3.19.8-ckt21

On 16.05.2016 18:58, Kamal Mostafa wrote: > > Queued up for 3.19-stable. Thanks very much for the backport, Philip. > > -Kamal > Thx. Due this fact I also found another issue with it. Somehow some other patch is needed to get it compiled with gcc 6.1 series.

[PATCH] Staging: comedi: quatech_daqp_cs.c: fixed a warning issue

Fixed a warning issue to use 'unsigned int'. Signed-off-by: Amit Ghadge --- drivers/staging/comedi/drivers/quatech_daqp_cs.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/staging/comedi/drivers/quatech_daqp_cs.c

[PATCH] Staging: comedi: quatech_daqp_cs.c: fixed a warning issue

Fixed a warning issue to use 'unsigned int'. Signed-off-by: Amit Ghadge --- drivers/staging/comedi/drivers/quatech_daqp_cs.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/staging/comedi/drivers/quatech_daqp_cs.c b/drivers/staging/comedi/drivers/quatech_daqp_cs.c

Re: [rcu_sched stall] regression/miss-config ?

On Mon, May 16, 2016 at 09:33:57AM -0700, Santosh Shilimkar wrote: > On 5/16/2016 5:03 AM, Paul E. McKenney wrote: > >On Sun, May 15, 2016 at 09:35:40PM -0700, santosh.shilim...@oracle.com wrote: > >>On 5/15/16 2:18 PM, Santosh Shilimkar wrote: > >>>Hi Paul, > >>> > >>>I was asking Sasha about [1]

Re: [rcu_sched stall] regression/miss-config ?

On Mon, May 16, 2016 at 09:33:57AM -0700, Santosh Shilimkar wrote: > On 5/16/2016 5:03 AM, Paul E. McKenney wrote: > >On Sun, May 15, 2016 at 09:35:40PM -0700, santosh.shilim...@oracle.com wrote: > >>On 5/15/16 2:18 PM, Santosh Shilimkar wrote: > >>>Hi Paul, > >>> > >>>I was asking Sasha about [1]

Re: Linux v4.6 does not work with Centos 7 (Radeon) but works with Linux v4.5

On 5/15/16, OenHan wrote: > Maybe you should install kexec-tools or uncheck kdump options in .config: > > rpm -qf /lib/kdump/kdump-lib.sh > kexec-tools-2.0.7-38.el7_2.1.x86_64 > > > Thanks > > Oen Han > Updated the package and it fixed the kdump problem. The other problem

Re: Linux v4.6 does not work with Centos 7 (Radeon) but works with Linux v4.5

On 5/15/16, OenHan wrote: > Maybe you should install kexec-tools or uncheck kdump options in .config: > > rpm -qf /lib/kdump/kdump-lib.sh > kexec-tools-2.0.7-38.el7_2.1.x86_64 > > > Thanks > > Oen Han > Updated the package and it fixed the kdump problem. The other problem with firmware was

Re: [RFC PATCH v2 17/18] livepatch: change to a per-task consistency model

On Mon, May 09, 2016 at 11:41:37AM +0200, Miroslav Benes wrote: > > +void klp_init_transition(struct klp_patch *patch, int state) > > +{ > > + struct task_struct *g, *task; > > + unsigned int cpu; > > + struct klp_object *obj; > > + struct klp_func *func; > > + int initial_state =

Re: [RFC PATCH v2 17/18] livepatch: change to a per-task consistency model

On Mon, May 09, 2016 at 11:41:37AM +0200, Miroslav Benes wrote: > > +void klp_init_transition(struct klp_patch *patch, int state) > > +{ > > + struct task_struct *g, *task; > > + unsigned int cpu; > > + struct klp_object *obj; > > + struct klp_func *func; > > + int initial_state =

Re: [PATCH net-next v2 0/6] hv_netvsc: avoid races on mtu change/set channels

From: Vitaly Kuznetsov Date: Fri, 13 May 2016 13:55:19 +0200 > Changes since v1: > - Rebased to net-next [Haiyang Zhang] > > Original description: > > MTU change and set channels operations are implemented as netvsc device > re-creation destroying internal structures

Re: [PATCH net-next v2 0/6] hv_netvsc: avoid races on mtu change/set channels

From: Vitaly Kuznetsov Date: Fri, 13 May 2016 13:55:19 +0200 > Changes since v1: > - Rebased to net-next [Haiyang Zhang] > > Original description: > > MTU change and set channels operations are implemented as netvsc device > re-creation destroying internal structures (struct net_device stays).

Re: [RFC][PATCH 4/7] sched: Replace sd_busy/nr_busy_cpus with sched_domain_shared

On 16/05/16 18:02, Peter Zijlstra wrote: > On Mon, May 16, 2016 at 04:31:08PM +0100, Dietmar Eggemann wrote: >> On 09/05/16 11:48, Peter Zijlstra wrote: >> >> Couldn't you just always access sd->shared via >> sd = rcu_dereference(per_cpu(sd_llc, cpu)) for >> updating nr_busy_cpus? > > Sure; but

RE: [PATCH v2 6/8] crypto: caam - handle core endianness != caam endianness

> There are SoCs like LS1043A where CAAM endianness (BE) does not match > the default endianness of the core (LE). > Moreover, there are requirements for the driver to handle cases like > CPU_BIG_ENDIAN=y on ARM-based SoCs. > This requires for a complete rewrite of the I/O accessors. > >

Re: [RFC][PATCH 4/7] sched: Replace sd_busy/nr_busy_cpus with sched_domain_shared

On 16/05/16 18:02, Peter Zijlstra wrote: > On Mon, May 16, 2016 at 04:31:08PM +0100, Dietmar Eggemann wrote: >> On 09/05/16 11:48, Peter Zijlstra wrote: >> >> Couldn't you just always access sd->shared via >> sd = rcu_dereference(per_cpu(sd_llc, cpu)) for >> updating nr_busy_cpus? > > Sure; but

RE: [PATCH v2 6/8] crypto: caam - handle core endianness != caam endianness

> There are SoCs like LS1043A where CAAM endianness (BE) does not match > the default endianness of the core (LE). > Moreover, there are requirements for the driver to handle cases like > CPU_BIG_ENDIAN=y on ARM-based SoCs. > This requires for a complete rewrite of the I/O accessors. > >

[PATCH v2 1/1] userfaultfd: don't pin the user memory in userfaultfd_file_create()

userfaultfd_file_create() increments mm->mm_users; this means that the memory won't be unmapped/freed if mm owner exits/execs, and UFFDIO_COPY after that can populate the orphaned mm more. Change userfaultfd_file_create() and userfaultfd_ctx_put() to use mm->mm_count to pin mm_struct. This means

[PATCH v2 1/1] userfaultfd: don't pin the user memory in userfaultfd_file_create()

userfaultfd_file_create() increments mm->mm_users; this means that the memory won't be unmapped/freed if mm owner exits/execs, and UFFDIO_COPY after that can populate the orphaned mm more. Change userfaultfd_file_create() and userfaultfd_ctx_put() to use mm->mm_count to pin mm_struct. This means

Re: [PATCH v2] locking/rwsem: Add reader-owned state to the owner field

On Mon, May 16, 2016 at 07:17:42AM -0700, Peter Hurley wrote: > On 05/16/2016 05:17 AM, Paul E. McKenney wrote: > > On Mon, May 16, 2016 at 01:09:48PM +0200, Peter Zijlstra wrote: > >> On Fri, May 13, 2016 at 10:58:05AM -0700, Peter Hurley wrote: > Note that barrier() and READ_ONCE() have

Re: [PATCH v10 7/8] i2c: rk3x: add i2c support for rk3399 soc

David, On Mon, May 16, 2016 at 7:05 AM, David Wu wrote: > - new method to caculate i2c timings for rk3399: > There was an timing issue about "repeated start" time at the I2C > controller of version0, controller appears to drop SDA at .875x (7/8) > programmed clk

Re: [PATCH v2] locking/rwsem: Add reader-owned state to the owner field

On Mon, May 16, 2016 at 07:17:42AM -0700, Peter Hurley wrote: > On 05/16/2016 05:17 AM, Paul E. McKenney wrote: > > On Mon, May 16, 2016 at 01:09:48PM +0200, Peter Zijlstra wrote: > >> On Fri, May 13, 2016 at 10:58:05AM -0700, Peter Hurley wrote: > Note that barrier() and READ_ONCE() have

Re: [PATCH v10 7/8] i2c: rk3x: add i2c support for rk3399 soc

David, On Mon, May 16, 2016 at 7:05 AM, David Wu wrote: > - new method to caculate i2c timings for rk3399: > There was an timing issue about "repeated start" time at the I2C > controller of version0, controller appears to drop SDA at .875x (7/8) > programmed clk high. On version 1 of the

Re: [PATCH] mtd: Adding of_mtd_info_get to get mtd_info from devicetree

On Mon, 16 May 2016 09:30:10 -0700 Moritz Fischer wrote: > Hi Boris, > > On Mon, May 16, 2016 at 1:05 AM, Boris Brezillon > wrote: > > >> Here are a few questions (I'm assuming the netdev + MAC address case): > >> - how would you

Re: [Intel-wired-lan] [PATCH] ixgbe: take online CPU number as MQ max limit when alloc_etherdev_mq()

[...] >>> ixgbe_main.c. All you are doing with this patch is denying the user >>> choice with this change as they then are not allowed to set more >> >> Yes, it is purposed to deny configuration that doesn't benefit. > > Doesn't benefit who? It is obvious you don't understand how DCB is >

Re: [PATCH] mtd: Adding of_mtd_info_get to get mtd_info from devicetree

On Mon, 16 May 2016 09:30:10 -0700 Moritz Fischer wrote: > Hi Boris, > > On Mon, May 16, 2016 at 1:05 AM, Boris Brezillon > wrote: > > >> Here are a few questions (I'm assuming the netdev + MAC address case): > >> - how would you link the net/PHY device to the MTD partition storing > >> the

Re: [Intel-wired-lan] [PATCH] ixgbe: take online CPU number as MQ max limit when alloc_etherdev_mq()

[...] >>> ixgbe_main.c. All you are doing with this patch is denying the user >>> choice with this change as they then are not allowed to set more >> >> Yes, it is purposed to deny configuration that doesn't benefit. > > Doesn't benefit who? It is obvious you don't understand how DCB is >

Re: [PATCH] dell_rbu: Don't fallback to userhelper when loading firmware

On 05/16/2016 08:41 AM, Mario Limonciello wrote: dell_rbu previously would allow a userspace application to craft the payload after dell_rbu was loaded and abuse the udev userspace API. Instead require the payload to be crafted and placed in /lib/firmware/dell_rbu ahead of time. This adjusts

Re: [PATCH] dell_rbu: Don't fallback to userhelper when loading firmware

On 05/16/2016 08:41 AM, Mario Limonciello wrote: dell_rbu previously would allow a userspace application to craft the payload after dell_rbu was loaded and abuse the udev userspace API. Instead require the payload to be crafted and placed in /lib/firmware/dell_rbu ahead of time. This adjusts

Re: next: suspicious RCU usage message since commit 'rcu: Remove superfluous versions of rcu_read_lock_sched_held()'

On Sat, May 14, 2016 at 08:42:46AM -0700, Guenter Roeck wrote: > On 04/25/2016 01:49 PM, Paul E. McKenney wrote: > >On Mon, Apr 25, 2016 at 01:25:10PM -0700, Guenter Roeck wrote: > >>On Mon, Apr 25, 2016 at 10:12:39AM -0700, Paul E. McKenney wrote: > >>>On Sun, Apr 24, 2016 at 11:26:41PM -0700,

Re: next: suspicious RCU usage message since commit 'rcu: Remove superfluous versions of rcu_read_lock_sched_held()'

On Sat, May 14, 2016 at 08:42:46AM -0700, Guenter Roeck wrote: > On 04/25/2016 01:49 PM, Paul E. McKenney wrote: > >On Mon, Apr 25, 2016 at 01:25:10PM -0700, Guenter Roeck wrote: > >>On Mon, Apr 25, 2016 at 10:12:39AM -0700, Paul E. McKenney wrote: > >>>On Sun, Apr 24, 2016 at 11:26:41PM -0700,

[GIT PULL] scheduler changes for v4.7

Linus, Please pull the latest sched-core-for-linus git tree from: git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git sched-core-for-linus # HEAD: ef0491ea17f8019821c7e9c8e801184ecf17f85a ARM: Hide finish_arch_post_lock_switch() from modules - massive CPU hotplug rework (Thomas

[GIT PULL] scheduler changes for v4.7

Linus, Please pull the latest sched-core-for-linus git tree from: git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git sched-core-for-linus # HEAD: ef0491ea17f8019821c7e9c8e801184ecf17f85a ARM: Hide finish_arch_post_lock_switch() from modules - massive CPU hotplug rework (Thomas

Re: [PATCH] regulator: axp20x: Add support for the (external) drivebus regulator

Hi, On Sun, May 15, 2016 at 1:55 AM, Hans de Goede wrote: > The axp20x pmics have 2 power inputs, one called ACIN which is intended > for to be supplied via a powerbarrel on the board and one called VBUS > which is intended to be supplied via an otg connector. > > In the

Re: [PATCH] regulator: axp20x: Add support for the (external) drivebus regulator

Hi, On Sun, May 15, 2016 at 1:55 AM, Hans de Goede wrote: > The axp20x pmics have 2 power inputs, one called ACIN which is intended > for to be supplied via a powerbarrel on the board and one called VBUS > which is intended to be supplied via an otg connector. > > In the VBUS case the pmic needs

Re: [patch V4 09/31] bitops: Add x86-specific parity functions

On Mon, May 16, 2016 at 11:49:05PM +0800, Zhaoxiu Zeng wrote: > On 2016/5/11 17:31, Peter Zijlstra wrote: > > Please use the GEN_*_RMWcc() stuff to avoid the setpo where possible. > > Setpo is better. > In most cases, we need to store the parity, or compare it with other > variables. > > For

Re: [patch V4 09/31] bitops: Add x86-specific parity functions

On Mon, May 16, 2016 at 11:49:05PM +0800, Zhaoxiu Zeng wrote: > On 2016/5/11 17:31, Peter Zijlstra wrote: > > Please use the GEN_*_RMWcc() stuff to avoid the setpo where possible. > > Setpo is better. > In most cases, we need to store the parity, or compare it with other > variables. > > For

Re: [PATCH 20/25] arm64:ilp32: add sys_ilp32.c and a separate table (in entry.S) to use it

On Sat, May 14, 2016 at 06:03:52PM +0300, Yury Norov wrote: > +SYSCALL_DEFINE6(mmap2, unsigned long, addr, unsigned long, len, > + unsigned long, prot, unsigned long, flags, unsigned long, fd, > + unsigned long, pgoff) To avoid the types confusion we could add __SC_WRAP to mmap2 in

Re: [PATCH 20/25] arm64:ilp32: add sys_ilp32.c and a separate table (in entry.S) to use it

On Sat, May 14, 2016 at 06:03:52PM +0300, Yury Norov wrote: > +SYSCALL_DEFINE6(mmap2, unsigned long, addr, unsigned long, len, > + unsigned long, prot, unsigned long, flags, unsigned long, fd, > + unsigned long, pgoff) To avoid the types confusion we could add __SC_WRAP to mmap2 in

[GIT PULL] RAS changes for v4.7

Linus, Please pull the latest ras-core-for-linus git tree from: git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git ras-core-for-linus # HEAD: 754a92305980b1fecffe033dd3fdc49c37f8e4b0 x86/RAS: Add SMCA support to AMD Error Injector Main changes in this cycle were: - AMD MCE/RAS

[GIT PULL] RAS changes for v4.7

Linus, Please pull the latest ras-core-for-linus git tree from: git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git ras-core-for-linus # HEAD: 754a92305980b1fecffe033dd3fdc49c37f8e4b0 x86/RAS: Add SMCA support to AMD Error Injector Main changes in this cycle were: - AMD MCE/RAS

Re: [RFC][PATCH 4/7] sched: Replace sd_busy/nr_busy_cpus with sched_domain_shared

On Mon, May 16, 2016 at 04:31:08PM +0100, Dietmar Eggemann wrote: > On 09/05/16 11:48, Peter Zijlstra wrote: > > Couldn't you just always access sd->shared via > sd = rcu_dereference(per_cpu(sd_llc, cpu)) for > updating nr_busy_cpus? Sure; but why would I want to add that extra dereference? Note

Re: [RFC][PATCH 4/7] sched: Replace sd_busy/nr_busy_cpus with sched_domain_shared

On Mon, May 16, 2016 at 04:31:08PM +0100, Dietmar Eggemann wrote: > On 09/05/16 11:48, Peter Zijlstra wrote: > > Couldn't you just always access sd->shared via > sd = rcu_dereference(per_cpu(sd_llc, cpu)) for > updating nr_busy_cpus? Sure; but why would I want to add that extra dereference? Note

SCHED_DEADLINE cpudeadline.{h,c} fixup

Hi, looking at the SCHED_DEADLINE code, I spotted an opportunity to make cpudeadline.c faster, in that we can skip real swaps during re-heapify()ication of items after addition/removal. As such ops are done under a domain spinlock, it sounded like an interesting try. Indeed, I've got a speed-up

SCHED_DEADLINE cpudeadline.{h,c} fixup

Hi, looking at the SCHED_DEADLINE code, I spotted an opportunity to make cpudeadline.c faster, in that we can skip real swaps during re-heapify()ication of items after addition/removal. As such ops are done under a domain spinlock, it sounded like an interesting try. Indeed, I've got a speed-up

Re: [3.19.y-ckt stable] Linux 3.19.8-ckt21

On Thu, May 12, 2016 at 09:07:52PM +0200, Philip Müller wrote: > Hi Kamal, > > seems using a toolchain with gcc 6.1 creates funny new issues like this: > > In file included from include/linux/compiler.h:54:0, > from include/uapi/linux/stddef.h:1, > from

Re: [3.19.y-ckt stable] Linux 3.19.8-ckt21

On Thu, May 12, 2016 at 09:07:52PM +0200, Philip Müller wrote: > Hi Kamal, > > seems using a toolchain with gcc 6.1 creates funny new issues like this: > > In file included from include/linux/compiler.h:54:0, > from include/uapi/linux/stddef.h:1, > from

[PATCH v2 2/5] of: Support hashtable lookups for phandles

When a device tree contains a lot of phandles, resolving one takes time because the original method uses a search against all nodes (not just the ones with phandles). Signed-off-by: Pantelis Antoniou --- drivers/of/base.c | 41

Re: [RFC v2 PATCH 0/8] VFS:userns: support portable root filesystems

Seth Forshee writes: > On Sat, May 14, 2016 at 09:21:55PM -0500, Eric W. Biederman wrote: >> I have slowly been working with Seth Forshee on these issues as >> the last thing I want is to introduce more security bugs right now. >> Seth being a braver man than I

[PATCH v2 5/5] of: overlay: Add pr_fmt for clarity

There are a bunch of pr_.*() messages in the file, use a common pr_fmt for making them a little bit shorter. Signed-off-by: Pantelis Antoniou --- drivers/of/overlay.c | 84 1 file changed, 38 insertions(+), 46

[PATCH v2 4/5] of: overlay: Pick up label symbols from overlays.

Insert overlay symbols to the base tree when applied. This makes it possible to apply an overlay that references a label that a previously inserted overlay had. Signed-off-by: Pantelis Antoniou --- drivers/of/overlay.c | 93

[PATCH v2 2/5] of: Support hashtable lookups for phandles

When a device tree contains a lot of phandles, resolving one takes time because the original method uses a search against all nodes (not just the ones with phandles). Signed-off-by: Pantelis Antoniou --- drivers/of/base.c | 41 ++---

Re: [RFC v2 PATCH 0/8] VFS:userns: support portable root filesystems

Seth Forshee writes: > On Sat, May 14, 2016 at 09:21:55PM -0500, Eric W. Biederman wrote: >> I have slowly been working with Seth Forshee on these issues as >> the last thing I want is to introduce more security bugs right now. >> Seth being a braver man than I am has already merged his

[PATCH v2 5/5] of: overlay: Add pr_fmt for clarity

There are a bunch of pr_.*() messages in the file, use a common pr_fmt for making them a little bit shorter. Signed-off-by: Pantelis Antoniou --- drivers/of/overlay.c | 84 1 file changed, 38 insertions(+), 46 deletions(-) diff --git

[PATCH v2 4/5] of: overlay: Pick up label symbols from overlays.

Insert overlay symbols to the base tree when applied. This makes it possible to apply an overlay that references a label that a previously inserted overlay had. Signed-off-by: Pantelis Antoniou --- drivers/of/overlay.c | 93 1 file changed,

[PATCH v2 0/5] of: generic infrastructure fixes

The first patch renames the *_node_sysfs methods to _node_post since this is more accurate when more work takes place besides sysfs tweaking when the next patch is using a hashtable for phandles. This is a win for very large blobs with a large number of phandles. Current we use an exhaustive

[PATCH v2 0/5] of: generic infrastructure fixes

The first patch renames the *_node_sysfs methods to _node_post since this is more accurate when more work takes place besides sysfs tweaking when the next patch is using a hashtable for phandles. This is a win for very large blobs with a large number of phandles. Current we use an exhaustive

[PATCH v2 3/5] of: unittest: hashed phandles unitest

Add a benchmarking hashed phandles unittest which report what kind of speed up we get switching to hashed phandle lookups. ### dt-test ### the hash method is 8.2 times faster than the original On the beaglebone we perform about 1877 phandle lookups until that point in the unittest. Each

[PATCH v2 1/5] of: rename *_node_sysfs to _node_post

Renames the *_node_sysfs methods to _node_post which is more accurate when more work takes place besides sysfs tweaking (as in with phandle hash management). Signed-off-by: Pantelis Antoniou --- drivers/of/base.c | 4 ++-- drivers/of/dynamic.c| 10

[PATCH v2 3/5] of: unittest: hashed phandles unitest

Add a benchmarking hashed phandles unittest which report what kind of speed up we get switching to hashed phandle lookups. ### dt-test ### the hash method is 8.2 times faster than the original On the beaglebone we perform about 1877 phandle lookups until that point in the unittest. Each

[PATCH v2 1/5] of: rename *_node_sysfs to _node_post

Renames the *_node_sysfs methods to _node_post which is more accurate when more work takes place besides sysfs tweaking (as in with phandle hash management). Signed-off-by: Pantelis Antoniou --- drivers/of/base.c | 4 ++-- drivers/of/dynamic.c| 10 +- drivers/of/of_private.h

Re: [PATCH] dt: add Atmel Captouch bindings

On Sat, May 14, 2016 at 7:52 AM, Rob Herring wrote: > On Tue, May 10, 2016 at 07:07:48PM -0700, Grant Grundler wrote: >> From: Daniel Hung-yu Wu >> >> Add binding for Atmel Capacitive Touch Button device. >> >> Signed-off-by: Daniel Hung-yu Wu

Re: [PATCH] dt: add Atmel Captouch bindings

On Sat, May 14, 2016 at 7:52 AM, Rob Herring wrote: > On Tue, May 10, 2016 at 07:07:48PM -0700, Grant Grundler wrote: >> From: Daniel Hung-yu Wu >> >> Add binding for Atmel Capacitive Touch Button device. >> >> Signed-off-by: Daniel Hung-yu Wu >> Signed-off-by: Grant Grundler >> --- >>

[PATCH] rcu: tree: correctly handle sparse possible CPUs

In many cases in the RCU tree code, we iterate over the set of CPUS for a leaf node described by rcu_node::grplo and rcu_node::grphi, checking per-cpu data for each CPU in this range. However, if the set of possible CPUs is sparse, some CPUs described in this range are not possible, and thus no

[PATCH] rcu: tree: correctly handle sparse possible CPUs

In many cases in the RCU tree code, we iterate over the set of CPUS for a leaf node described by rcu_node::grplo and rcu_node::grphi, checking per-cpu data for each CPU in this range. However, if the set of possible CPUs is sparse, some CPUs described in this range are not possible, and thus no

Re: [PATCH] usb: gadget: f_fs: report error if excess data received

> On 05/16/2016 06:05 PM, Michal Nazarewicz wrote: >> So I’ve been looking at AIO handling in f_fs and either I’m stupid or >> the code is broken. On Mon, May 16 2016, Lars-Peter Clausen wrote: > The code was broken. Fixed in commit 332a5b446b791 ("usb: gadget: > f_fs: Fix EFAULT generation for

Re: [PATCH] usb: gadget: f_fs: report error if excess data received

> On 05/16/2016 06:05 PM, Michal Nazarewicz wrote: >> So I’ve been looking at AIO handling in f_fs and either I’m stupid or >> the code is broken. On Mon, May 16 2016, Lars-Peter Clausen wrote: > The code was broken. Fixed in commit 332a5b446b791 ("usb: gadget: > f_fs: Fix EFAULT generation for

Re: [PATCH v10 6/8] dt-bindings: i2c: rk3x: add support for rk3399

On Mon, May 16, 2016 at 10:04:12PM +0800, David Wu wrote: > The bus clock and function clock are separated at rk3399, > and others use one clock as the bus clock and function clock. > > Signed-off-by: David Wu > Reviewed-by: Douglas Anderson >

Re: [PATCH v10 6/8] dt-bindings: i2c: rk3x: add support for rk3399

On Mon, May 16, 2016 at 10:04:12PM +0800, David Wu wrote: > The bus clock and function clock are separated at rk3399, > and others use one clock as the bus clock and function clock. > > Signed-off-by: David Wu > Reviewed-by: Douglas Anderson > Reviewed-by: Heiko Stuebner > Tested-by: Heiko

[PATCH v2 5/5] i2c: demux: Use changeset helpers for clarity

The changeset helpers are easier to use, use them instead of using the static property. Signed-off-by: Pantelis Antoniou --- drivers/i2c/muxes/i2c-demux-pinctrl.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git

[PATCH v2 5/5] i2c: demux: Use changeset helpers for clarity

The changeset helpers are easier to use, use them instead of using the static property. Signed-off-by: Pantelis Antoniou --- drivers/i2c/muxes/i2c-demux-pinctrl.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/drivers/i2c/muxes/i2c-demux-pinctrl.c

<    5   6   7   8   9   10   11   12   13   14   >