[GIT PULL] SMP bootup printout changes for v4.10

Linus, Please pull the latest core-smp-for-linus git tree from: git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git core-smp-for-linus # HEAD: 5dce2509506d16efd321939895ff7ffe1dc2 kernel/smp: Tell the user we're bringing up secondary CPUs Three changes to unify/standardize

[GIT PULL] SMP bootup printout changes for v4.10

Linus, Please pull the latest core-smp-for-linus git tree from: git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git core-smp-for-linus # HEAD: 5dce2509506d16efd321939895ff7ffe1dc2 kernel/smp: Tell the user we're bringing up secondary CPUs Three changes to unify/standardize

Re: [PATCH v6 0/3] spi-nor: Add support for Intel SPI serial flash controller

On Fri, 09 Dec 2016, Marek Vasut wrote: > On 12/09/2016 01:25 PM, Mika Westerberg wrote: > > On Fri, Dec 09, 2016 at 08:57:53AM +, Lee Jones wrote: > >> On Wed, 07 Dec 2016, Marek Vasut wrote: > >> > >>> On 12/07/2016 09:53 AM, Mika Westerberg wrote: > On Tue, Dec 06, 2016 at 09:45:25AM

Re: [PATCH v6 0/3] spi-nor: Add support for Intel SPI serial flash controller

On Fri, 09 Dec 2016, Marek Vasut wrote: > On 12/09/2016 01:25 PM, Mika Westerberg wrote: > > On Fri, Dec 09, 2016 at 08:57:53AM +, Lee Jones wrote: > >> On Wed, 07 Dec 2016, Marek Vasut wrote: > >> > >>> On 12/07/2016 09:53 AM, Mika Westerberg wrote: > On Tue, Dec 06, 2016 at 09:45:25AM

[PATCH] drivers: media: i2c: constify v4l2_subdev_* structures

v4l2_subdev_{core/pad/video}_ops structures are stored in the fields of the v4l2_subdev_ops structure which are of type const. Also, v4l2_subdev_ops structure is passed to a function having its argument of type const. As these structures are never modified, so declare them as const. Done using

[PATCH] drivers: media: i2c: constify v4l2_subdev_* structures

v4l2_subdev_{core/pad/video}_ops structures are stored in the fields of the v4l2_subdev_ops structure which are of type const. Also, v4l2_subdev_ops structure is passed to a function having its argument of type const. As these structures are never modified, so declare them as const. Done using

Re: [PATCH v6 0/8] Add PWM and IIO timer drivers for STM32

On Fri, 09 Dec 2016, Benjamin Gaignard wrote: > version 6: > - rename stm32-gptimer in stm32-timers. > - change "st,stm32-gptimer" compatible to "st,stm32-timers". > - modify "st,breakinput" parameter in pwm part. > - split DT patch in 2 > > version 5: > - fix comments done on version 4 > -

Re: [PATCH v6 0/8] Add PWM and IIO timer drivers for STM32

On Fri, 09 Dec 2016, Benjamin Gaignard wrote: > version 6: > - rename stm32-gptimer in stm32-timers. > - change "st,stm32-gptimer" compatible to "st,stm32-timers". > - modify "st,breakinput" parameter in pwm part. > - split DT patch in 2 > > version 5: > - fix comments done on version 4 > -

Re: [PATCH v6 1/8] MFD: add bindings for STM32 Timers driver

On Fri, 09 Dec 2016, Benjamin Gaignard wrote: > Add bindings information for STM32 Timers > > version 6: > - rename stm32-gtimer to stm32-timers > - change compatible > - add description about the IPs > > version 2: > - rename stm32-mfd-timer to stm32-gptimer > - only keep one compatible string

Re: [PATCH v6 1/8] MFD: add bindings for STM32 Timers driver

On Fri, 09 Dec 2016, Benjamin Gaignard wrote: > Add bindings information for STM32 Timers > > version 6: > - rename stm32-gtimer to stm32-timers > - change compatible > - add description about the IPs > > version 2: > - rename stm32-mfd-timer to stm32-gptimer > - only keep one compatible string

Re: [PATCH v6 2/8] MFD: add STM32 Timers driver

On Fri, 09 Dec 2016, Benjamin Gaignard wrote: > This hardware block could at used at same time for PWM generation > and IIO timers. > PWM and IIO timer configuration are mixed in the same registers > so we need a multi fonction driver to be able to share those registers. > > version 6: > -

Re: [PATCH v6 2/8] MFD: add STM32 Timers driver

On Fri, 09 Dec 2016, Benjamin Gaignard wrote: > This hardware block could at used at same time for PWM generation > and IIO timers. > PWM and IIO timer configuration are mixed in the same registers > so we need a multi fonction driver to be able to share those registers. > > version 6: > -

Re: [PATCH v8 3/3] iio: adc: add support for Allwinner SoCs ADC

Hi Maxime, On 10/12/2016 10:44, Maxime Ripard wrote: > Hi, > > Just some minor comments. > > On Fri, Dec 09, 2016 at 11:22:36AM +0100, Quentin Schulz wrote: >> +/* >> + * Since the thermal sensor needs the IP to be in touchscreen mode and >> + * there is no register to know if the

Re: [PATCH v8 3/3] iio: adc: add support for Allwinner SoCs ADC

Hi Maxime, On 10/12/2016 10:44, Maxime Ripard wrote: > Hi, > > Just some minor comments. > > On Fri, Dec 09, 2016 at 11:22:36AM +0100, Quentin Schulz wrote: >> +/* >> + * Since the thermal sensor needs the IP to be in touchscreen mode and >> + * there is no register to know if the

Re: [media] bt8xx: One function call less in bttv_input_init() after error detection

On 12/12/16 00:33, SF Markus Elfring wrote: >>> I would prefer a safer coding style for the corresponding >>> exception handling. >> >> Can you please point out what is wrong in the current code > > Is it useful to reconsider the software situation that another memory > allocation is attempted

Re: [media] bt8xx: One function call less in bttv_input_init() after error detection

On 12/12/16 00:33, SF Markus Elfring wrote: >>> I would prefer a safer coding style for the corresponding >>> exception handling. >> >> Can you please point out what is wrong in the current code > > Is it useful to reconsider the software situation that another memory > allocation is attempted

[PATCH RFC] clk: wm831x: fix usleep_range with bad range

The delay here is not in atomic context and does not seem critical with respect to precision, but usleep_range(min,max) with min==max results in giving the timer subsystem no room to optimize uncritical delays. Fix this by setting the range to 2000,3000 us. Fixes: commit f05259a6ffa4 ("clk:

[PATCH RFC] clk: wm831x: fix usleep_range with bad range

The delay here is not in atomic context and does not seem critical with respect to precision, but usleep_range(min,max) with min==max results in giving the timer subsystem no room to optimize uncritical delays. Fix this by setting the range to 2000,3000 us. Fixes: commit f05259a6ffa4 ("clk:

Re: [media] bt8xx: One function call less in bttv_input_init() after error detection

>> I would prefer a safer coding style for the corresponding >> exception handling. > > Can you please point out what is wrong in the current code Is it useful to reconsider the software situation that another memory allocation is attempted when it could be determined that a previous one failed

Re: [media] bt8xx: One function call less in bttv_input_init() after error detection

>> I would prefer a safer coding style for the corresponding >> exception handling. > > Can you please point out what is wrong in the current code Is it useful to reconsider the software situation that another memory allocation is attempted when it could be determined that a previous one failed

[GIT PULL] RCU changes for v4.10

Linus, Please pull the latest core-rcu-for-linus git tree from: git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git core-rcu-for-linus # HEAD: af91a81131aee3e233a977632a23b839857a327b Merge branch 'for-mingo' of git://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu into

[GIT PULL] RCU changes for v4.10

Linus, Please pull the latest core-rcu-for-linus git tree from: git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git core-rcu-for-linus # HEAD: af91a81131aee3e233a977632a23b839857a327b Merge branch 'for-mingo' of git://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu into

[PATCH] ACPI: small formatting fixes

A quick cleanup that passes scripts/checkpatch.pl -f . Signed-off-by: Nick Desaulniers --- arch/x86/kernel/acpi/cstate.c | 20 ++-- 1 file changed, 10 insertions(+), 10 deletions(-) diff --git a/arch/x86/kernel/acpi/cstate.c

[PATCH] ACPI: small formatting fixes

A quick cleanup that passes scripts/checkpatch.pl -f . Signed-off-by: Nick Desaulniers --- arch/x86/kernel/acpi/cstate.c | 20 ++-- 1 file changed, 10 insertions(+), 10 deletions(-) diff --git a/arch/x86/kernel/acpi/cstate.c b/arch/x86/kernel/acpi/cstate.c index

[PATCH] serial: mxs-auart: support CMSPAR termios cflag

If CMSPAR is set in the c_cflag of termios, "stick" parity is enabled. Tested on an i.MX28 system Signed-off-by: Wolfgang Ocker --- v2: require PARENB to be also set in termios' c_cflag for CMSPAR --- drivers/tty/serial/mxs-auart.c | 3 +++ 1 file changed, 3 insertions(+)

[PATCH] serial: mxs-auart: support CMSPAR termios cflag

If CMSPAR is set in the c_cflag of termios, "stick" parity is enabled. Tested on an i.MX28 system Signed-off-by: Wolfgang Ocker --- v2: require PARENB to be also set in termios' c_cflag for CMSPAR --- drivers/tty/serial/mxs-auart.c | 3 +++ 1 file changed, 3 insertions(+) diff --git

Re: [PATCH 1/3] arm: hisi: add ARCH_MULTI_V5 support

On 2016/12/9 23:07, Marty Plummer wrote: > On 12/04/2016 08:03 PM, Jiancheng Xue wrote: >> Hi Arnd, >> >> On 2016/10/17 21:48, Arnd Bergmann wrote: >>> On Monday, October 17, 2016 8:07:03 PM CEST Pan Wen wrote: Add support for some HiSilicon SoCs which depend on ARCH_MULTI_V5.

Re: [PATCH 1/3] arm: hisi: add ARCH_MULTI_V5 support

On 2016/12/9 23:07, Marty Plummer wrote: > On 12/04/2016 08:03 PM, Jiancheng Xue wrote: >> Hi Arnd, >> >> On 2016/10/17 21:48, Arnd Bergmann wrote: >>> On Monday, October 17, 2016 8:07:03 PM CEST Pan Wen wrote: Add support for some HiSilicon SoCs which depend on ARCH_MULTI_V5.

[PATCH] Input: elantech - force a module ignore ABS mode

One Elan sample which sample version is 0x74 and hw_version is 0x04 has a bug in abs mode, so let it run in default mode Signed-off-by: KT Liao --- drivers/input/mouse/elantech.c | 7 +++ 1 file changed, 7 insertions(+) diff --git a/drivers/input/mouse/elantech.c

[PATCH] Input: elantech - force a module ignore ABS mode

One Elan sample which sample version is 0x74 and hw_version is 0x04 has a bug in abs mode, so let it run in default mode Signed-off-by: KT Liao --- drivers/input/mouse/elantech.c | 7 +++ 1 file changed, 7 insertions(+) diff --git a/drivers/input/mouse/elantech.c

Re: [PATCH 2/2] kcov: make kcov work properly with KASLR enabled

On Sun, Dec 11, 2016 at 10:37 PM, Alexander Popov wrote: > On 11.12.2016 12:32, Dmitry Vyukov wrote: >> On Sun, Dec 11, 2016 at 1:50 AM, Alexander Popov >> wrote: >>> Subtract KASLR offset from the kernel addresses reported by kcov. >>> Tested on

Re: [PATCH 2/2] kcov: make kcov work properly with KASLR enabled

On Sun, Dec 11, 2016 at 10:37 PM, Alexander Popov wrote: > On 11.12.2016 12:32, Dmitry Vyukov wrote: >> On Sun, Dec 11, 2016 at 1:50 AM, Alexander Popov >> wrote: >>> Subtract KASLR offset from the kernel addresses reported by kcov. >>> Tested on x86_64 and AArch64 (Hikey LeMaker). >>> >>>

[tip:sched/core] sched/core: Fix find_idlest_group() for fork

Commit-ID: f519a3f1c6b7a990e5aed37a8f853c6ecfdee945 Gitweb: http://git.kernel.org/tip/f519a3f1c6b7a990e5aed37a8f853c6ecfdee945 Author: Vincent Guittot AuthorDate: Thu, 8 Dec 2016 17:56:53 +0100 Committer: Ingo Molnar CommitDate: Sun, 11 Dec

[tip:sched/core] sched/core: Fix find_idlest_group() for fork

Commit-ID: f519a3f1c6b7a990e5aed37a8f853c6ecfdee945 Gitweb: http://git.kernel.org/tip/f519a3f1c6b7a990e5aed37a8f853c6ecfdee945 Author: Vincent Guittot AuthorDate: Thu, 8 Dec 2016 17:56:53 +0100 Committer: Ingo Molnar CommitDate: Sun, 11 Dec 2016 13:10:56 +0100 sched/core: Fix

[tip:perf/core] perf/x86: Fix exclusion of BTS and LBR for Goldmont

Commit-ID: b0c1ef52959582144bbea9a2b37db7f4c9e399f7 Gitweb: http://git.kernel.org/tip/b0c1ef52959582144bbea9a2b37db7f4c9e399f7 Author: Andi Kleen AuthorDate: Thu, 8 Dec 2016 16:14:17 -0800 Committer: Ingo Molnar CommitDate: Sun, 11 Dec 2016

[tip:perf/core] perf/x86: Fix exclusion of BTS and LBR for Goldmont

Commit-ID: b0c1ef52959582144bbea9a2b37db7f4c9e399f7 Gitweb: http://git.kernel.org/tip/b0c1ef52959582144bbea9a2b37db7f4c9e399f7 Author: Andi Kleen AuthorDate: Thu, 8 Dec 2016 16:14:17 -0800 Committer: Ingo Molnar CommitDate: Sun, 11 Dec 2016 13:06:09 +0100 perf/x86: Fix exclusion of

[tip:locking/core] x86/paravirt: Fix bool return type for PVOP_CALL()

Commit-ID: 11f254dbb3a2e3f0d8552d0dd37f4faa432b6b16 Gitweb: http://git.kernel.org/tip/11f254dbb3a2e3f0d8552d0dd37f4faa432b6b16 Author: Peter Zijlstra AuthorDate: Thu, 8 Dec 2016 16:42:15 +0100 Committer: Ingo Molnar CommitDate: Sun, 11 Dec 2016

[tip:locking/core] x86/paravirt: Fix bool return type for PVOP_CALL()

Commit-ID: 11f254dbb3a2e3f0d8552d0dd37f4faa432b6b16 Gitweb: http://git.kernel.org/tip/11f254dbb3a2e3f0d8552d0dd37f4faa432b6b16 Author: Peter Zijlstra AuthorDate: Thu, 8 Dec 2016 16:42:15 +0100 Committer: Ingo Molnar CommitDate: Sun, 11 Dec 2016 13:09:20 +0100 x86/paravirt: Fix bool

[tip:sched/core] sched/core: Use load_avg for selecting idlest group

Commit-ID: 6b94780e45c17b83e3e75f8aaca5a328db583c74 Gitweb: http://git.kernel.org/tip/6b94780e45c17b83e3e75f8aaca5a328db583c74 Author: Vincent Guittot AuthorDate: Thu, 8 Dec 2016 17:56:54 +0100 Committer: Ingo Molnar CommitDate: Sun, 11 Dec

[tip:sched/core] sched/core: Use load_avg for selecting idlest group

Commit-ID: 6b94780e45c17b83e3e75f8aaca5a328db583c74 Gitweb: http://git.kernel.org/tip/6b94780e45c17b83e3e75f8aaca5a328db583c74 Author: Vincent Guittot AuthorDate: Thu, 8 Dec 2016 17:56:54 +0100 Committer: Ingo Molnar CommitDate: Sun, 11 Dec 2016 13:10:57 +0100 sched/core: Use load_avg

[tip:locking/core] x86/paravirt: Fix native_patch()

Commit-ID: 45dbea5f55c05980cbb4c30047c71a820cd3f282 Gitweb: http://git.kernel.org/tip/45dbea5f55c05980cbb4c30047c71a820cd3f282 Author: Peter Zijlstra AuthorDate: Thu, 8 Dec 2016 16:42:14 +0100 Committer: Ingo Molnar CommitDate: Sun, 11 Dec 2016

[tip:locking/core] x86/paravirt: Fix native_patch()

Commit-ID: 45dbea5f55c05980cbb4c30047c71a820cd3f282 Gitweb: http://git.kernel.org/tip/45dbea5f55c05980cbb4c30047c71a820cd3f282 Author: Peter Zijlstra AuthorDate: Thu, 8 Dec 2016 16:42:14 +0100 Committer: Ingo Molnar CommitDate: Sun, 11 Dec 2016 13:09:19 +0100 x86/paravirt: Fix

linux-next: Tree for Dec 12

Hi all, Please do not add any material for v4.11 to your linux-next included branches until after v4.10-rc1 has been released. Changes since 20161209: The vfs tree gained conflicts against the overlayfs and xfs trees. The vfs-miklos tree gained a cofnlict against the vfs tree. The hid tree

linux-next: Tree for Dec 12

Hi all, Please do not add any material for v4.11 to your linux-next included branches until after v4.10-rc1 has been released. Changes since 20161209: The vfs tree gained conflicts against the overlayfs and xfs trees. The vfs-miklos tree gained a cofnlict against the vfs tree. The hid tree

RE: [PATCH v6 2/2] crypto: add virtio-crypto driver

Hi, Michael & Herbert Because the virtio-crypto device emulation had been in QEMU 2.8, would you please merge the virtio-crypto driver for 4.10 if no other comments? If so, Miachel pls ack and/or review the patch, then Herbert will take it (I asked him last week). Thank you! Ps: Note on 4.10

RE: [PATCH v6 2/2] crypto: add virtio-crypto driver

Hi, Michael & Herbert Because the virtio-crypto device emulation had been in QEMU 2.8, would you please merge the virtio-crypto driver for 4.10 if no other comments? If so, Miachel pls ack and/or review the patch, then Herbert will take it (I asked him last week). Thank you! Ps: Note on 4.10

Re: Documenting the ioctl interfaces to discover relationships between namespaces

[Fixing Serge's address in my original CC] On 12/11/2016 11:30 PM, Eric W. Biederman wrote: > "Michael Kerrisk (man-pages)" writes: > >> [was: [PATCH 0/4 v3] Add an interface to discover relationships >> between namespaces] > > One small comment below. > >> >>

Re: Documenting the ioctl interfaces to discover relationships between namespaces

[Fixing Serge's address in my original CC] On 12/11/2016 11:30 PM, Eric W. Biederman wrote: > "Michael Kerrisk (man-pages)" writes: > >> [was: [PATCH 0/4 v3] Add an interface to discover relationships >> between namespaces] > > One small comment below. > >> >>Introspecting namespace

[PATCH RFC 1/1] mm, page_alloc: fix incorrect zone_statistics data

In commit b9f00e147f27 ("mm, page_alloc: reduce branches in zone_statistics"), it reconstructed codes to reduce the branch miss rate. Compared with the original logic, it assumed if !(flag & __GFP_OTHER_NODE) z->node would not be equal to preferred_zone->node. That seems to be incorrect. Fixes:

[PATCH RFC 1/1] mm, page_alloc: fix incorrect zone_statistics data

In commit b9f00e147f27 ("mm, page_alloc: reduce branches in zone_statistics"), it reconstructed codes to reduce the branch miss rate. Compared with the original logic, it assumed if !(flag & __GFP_OTHER_NODE) z->node would not be equal to preferred_zone->node. That seems to be incorrect. Fixes:

[PATCH RFC 0/1] mm, page_alloc: fix incorrect zone_statistics data

In commit b9f00e147f27 ("mm, page_alloc: reduce branches in zone_statistics"), it reconstructed the code to reduce the branch miss rate. Compared with the original logic, it assumed if !(flag & __GFP_OTHER_NODE) z->node would not be equal to preferred_zone->node. That seems to be incorrect.

[PATCH RFC 0/1] mm, page_alloc: fix incorrect zone_statistics data

In commit b9f00e147f27 ("mm, page_alloc: reduce branches in zone_statistics"), it reconstructed the code to reduce the branch miss rate. Compared with the original logic, it assumed if !(flag & __GFP_OTHER_NODE) z->node would not be equal to preferred_zone->node. That seems to be incorrect.

linux-next: manual merge of the akpm tree with the vfs tree

Hi all, Al let me know that he had put a newer version of the autofs patches into his vfs tree, so I have dropped the following patches from the akpm tree today: vfs: change d_manage() to take a struct path vfs: add path_is_mountpoint() helper vfs: fix boolreturn.cocci warnings vfs: add

linux-next: manual merge of the akpm tree with the vfs tree

Hi all, Al let me know that he had put a newer version of the autofs patches into his vfs tree, so I have dropped the following patches from the akpm tree today: vfs: change d_manage() to take a struct path vfs: add path_is_mountpoint() helper vfs: fix boolreturn.cocci warnings vfs: add

linux-next: manual merge of the akpm tree with Linus' tree

Hi Andrew, Today's linux-next merge of the akpm tree got a conflict in: lib/radix-tree.c between commit: 2b41226b39b6 ("Revert "radix tree test suite: fix compilation"") from Linus' tree and patch: "reimplement IDR and IDA using the radix tree" from the akpm tree. I fixed it up (I

linux-next: manual merge of the akpm tree with Linus' tree

Hi Andrew, Today's linux-next merge of the akpm tree got a conflict in: lib/radix-tree.c between commit: 2b41226b39b6 ("Revert "radix tree test suite: fix compilation"") from Linus' tree and patch: "reimplement IDR and IDA using the radix tree" from the akpm tree. I fixed it up (I

Re: [PATCH v2] siphash: add cryptographically secure hashtable function

Hey Linus, On Mon, Dec 12, 2016 at 5:01 AM, Linus Torvalds wrote: > The above is extremely inefficient. Considering that most kernel data > would be expected to be smallish, that matters (ie the usual benchmark > would not be about hashing megabytes of data, but

Re: [PATCH v2] siphash: add cryptographically secure hashtable function

Hey Linus, On Mon, Dec 12, 2016 at 5:01 AM, Linus Torvalds wrote: > The above is extremely inefficient. Considering that most kernel data > would be expected to be smallish, that matters (ie the usual benchmark > would not be about hashing megabytes of data, but instead millions of > hashes of

Re: [PATCH v2] siphash: add cryptographically secure hashtable function

On Mon, Dec 12, 2016 at 04:48:17AM +0100, Jason A. Donenfeld wrote: > > diff --git a/lib/Makefile b/lib/Makefile > index 50144a3aeebd..71d398b04a74 100644 > --- a/lib/Makefile > +++ b/lib/Makefile > @@ -22,7 +22,8 @@ lib-y := ctype.o string.o vsprintf.o cmdline.o \ >sha1.o chacha20.o md5.o

Re: [PATCH v2] siphash: add cryptographically secure hashtable function

On Mon, Dec 12, 2016 at 04:48:17AM +0100, Jason A. Donenfeld wrote: > > diff --git a/lib/Makefile b/lib/Makefile > index 50144a3aeebd..71d398b04a74 100644 > --- a/lib/Makefile > +++ b/lib/Makefile > @@ -22,7 +22,8 @@ lib-y := ctype.o string.o vsprintf.o cmdline.o \ >sha1.o chacha20.o md5.o

[lkp-developer] [scsi] 8eea81e090: BUG:unable_to_handle_kernel

FYI, we noticed the following commit: commit: 8eea81e0903fcde1c28044ea66acc4c5c578f553 ("scsi: enable IO scheduling for scsi-mq") https://git.kernel.org/pub/scm/linux/kernel/git/axboe/linux-block.git blk-mq-legacy-sched.1 in testcase: boot on test machine: qemu-system-i386 -enable-kvm -cpu

[lkp-developer] [kernel/fork] cc639db4ac: BUG:using_smp_processor_id()in_preemptible

FYI, we noticed the following commit: commit: cc639db4acfeb459f3dcec080c6cfe11e36266e0 ("kernel/fork: use vfree_atomic() to free thread stack") https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master in testcase: iperf with following parameters: runtime: 300s

[lkp-developer] [scsi] 8eea81e090: BUG:unable_to_handle_kernel

FYI, we noticed the following commit: commit: 8eea81e0903fcde1c28044ea66acc4c5c578f553 ("scsi: enable IO scheduling for scsi-mq") https://git.kernel.org/pub/scm/linux/kernel/git/axboe/linux-block.git blk-mq-legacy-sched.1 in testcase: boot on test machine: qemu-system-i386 -enable-kvm -cpu

[lkp-developer] [kernel/fork] cc639db4ac: BUG:using_smp_processor_id()in_preemptible

FYI, we noticed the following commit: commit: cc639db4acfeb459f3dcec080c6cfe11e36266e0 ("kernel/fork: use vfree_atomic() to free thread stack") https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master in testcase: iperf with following parameters: runtime: 300s

Re: [PATCH v7 1/2] usb: xhci: plat: Enable runtime PM

Hi Robert, On 2 December 2016 at 05:46, Robert Foss wrote: > Enable runtime PM for the xhci-plat device so that the parent device > may implement runtime PM. > > Signed-off-by: Robert Foss > > Tested-by: Robert Foss

Re: [PATCH v7 1/2] usb: xhci: plat: Enable runtime PM

Hi Robert, On 2 December 2016 at 05:46, Robert Foss wrote: > Enable runtime PM for the xhci-plat device so that the parent device > may implement runtime PM. > > Signed-off-by: Robert Foss > > Tested-by: Robert Foss > --- > drivers/usb/host/xhci-plat.c | 29 +++-- > 1

Re: Tearing down DMA transfer setup after DMA client has finished

On Fri, Dec 09, 2016 at 07:23:17PM +0100, Mason wrote: > [ Dropping Mans to preserve his peace-of-mind ] > > On 09/12/2016 18:56, Vinod Koul wrote: > > On Fri, Dec 09, 2016 at 06:34:15PM +0100, Mason wrote: > >> On 09/12/2016 18:17, Vinod Koul wrote: > >> > >>> On Fri, Dec 09, 2016 at 11:25:57AM

Re: Tearing down DMA transfer setup after DMA client has finished

On Fri, Dec 09, 2016 at 07:23:17PM +0100, Mason wrote: > [ Dropping Mans to preserve his peace-of-mind ] > > On 09/12/2016 18:56, Vinod Koul wrote: > > On Fri, Dec 09, 2016 at 06:34:15PM +0100, Mason wrote: > >> On 09/12/2016 18:17, Vinod Koul wrote: > >> > >>> On Fri, Dec 09, 2016 at 11:25:57AM

Re: [PATCH] trace: extend trace_clock to support arch_arm clock counter

On 12/06/2016 05:43 PM, Will Deacon wrote: On Sun, Dec 04, 2016 at 02:06:23PM +0530, Srinivas Ramana wrote: On 12/02/2016 04:38 PM, Will Deacon wrote: On Fri, Dec 02, 2016 at 01:44:55PM +0530, Srinivas Ramana wrote: Extend the trace_clock to support the arch timer cycle counter so that we can

Re: [PATCH] trace: extend trace_clock to support arch_arm clock counter

On 12/06/2016 05:43 PM, Will Deacon wrote: On Sun, Dec 04, 2016 at 02:06:23PM +0530, Srinivas Ramana wrote: On 12/02/2016 04:38 PM, Will Deacon wrote: On Fri, Dec 02, 2016 at 01:44:55PM +0530, Srinivas Ramana wrote: Extend the trace_clock to support the arch timer cycle counter so that we can

Re: [PATCH v8 2/4] vcodec: mediatek: Add Mediatek JPEG Decoder Driver

Hi Rick, On Wed, Nov 30, 2016 at 11:08 AM, Rick Chang wrote: > Add v4l2 driver for Mediatek JPEG Decoder > > Signed-off-by: Rick Chang > Signed-off-by: Minghsiu Tsai > +static bool

Re: [PATCH v8 2/4] vcodec: mediatek: Add Mediatek JPEG Decoder Driver

Hi Rick, On Wed, Nov 30, 2016 at 11:08 AM, Rick Chang wrote: > Add v4l2 driver for Mediatek JPEG Decoder > > Signed-off-by: Rick Chang > Signed-off-by: Minghsiu Tsai > +static bool mtk_jpeg_check_resolution_change(struct mtk_jpeg_ctx *ctx, > +

linux-next: manual merge of the staging tree with the vfs tree

Hi Greg, Today's linux-next merge of the staging tree got a conflict in: drivers/staging/lustre/lustre/llite/statahead.c between commit: 7126bc2e8d60 ("lustre: switch to use of ->d_init()") from the vfs tree and commit: 3c8fb1b105cd ("staging: lustre: statahead: set sai_index_wait with

linux-next: manual merge of the staging tree with the vfs tree

Hi Greg, Today's linux-next merge of the staging tree got a conflict in: drivers/staging/lustre/lustre/llite/statahead.c between commit: 7126bc2e8d60 ("lustre: switch to use of ->d_init()") from the vfs tree and commit: 3c8fb1b105cd ("staging: lustre: statahead: set sai_index_wait with

Re: [V2] mtd: devices: docg3:- Handle return value of devm_ioremap.

On 12/12/2016 04:00 AM, Arvind Yadav wrote: > Here, If devm_ioremap will fail. It will return NULL. > Kernel can run into a NULL-pointer dereference. > > Signed-off-by: Arvind Yadav > --- > drivers/mtd/devices/docg3.c | 7 ++- > 1 file changed, 6 insertions(+), 1

Re: [V2] mtd: devices: docg3:- Handle return value of devm_ioremap.

On 12/12/2016 04:00 AM, Arvind Yadav wrote: > Here, If devm_ioremap will fail. It will return NULL. > Kernel can run into a NULL-pointer dereference. > > Signed-off-by: Arvind Yadav > --- > drivers/mtd/devices/docg3.c | 7 ++- > 1 file changed, 6 insertions(+), 1 deletion(-) > > diff --git

Re: [PATCH v2] siphash: add cryptographically secure hashtable function

On Sun, Dec 11, 2016 at 7:48 PM, Jason A. Donenfeld wrote: > + switch (left) { > + case 7: b |= ((u64)data[6]) << 48; > + case 6: b |= ((u64)data[5]) << 40; > + case 5: b |= ((u64)data[4]) << 32; > + case 4: b |=

Re: [PATCH v2] siphash: add cryptographically secure hashtable function

On Sun, Dec 11, 2016 at 7:48 PM, Jason A. Donenfeld wrote: > + switch (left) { > + case 7: b |= ((u64)data[6]) << 48; > + case 6: b |= ((u64)data[5]) << 40; > + case 5: b |= ((u64)data[4]) << 32; > + case 4: b |= ((u64)data[3]) << 24;

Re: usb:xhci: support disable usb2 LPM Remote Wakeup

On Sat, Dec 10, 2016 at 4:36 AM, Rob Herring wrote: > On Sun, Dec 04, 2016 at 07:42:01PM +0700, Thang Q. Nguyen wrote: >> From: Thang Nguyen >> >> As per USB 2.0 link power management addendum ECN, table 1-2, page 4, >> device or host initiated via resume

Re: usb:xhci: support disable usb2 LPM Remote Wakeup

On Sat, Dec 10, 2016 at 4:36 AM, Rob Herring wrote: > On Sun, Dec 04, 2016 at 07:42:01PM +0700, Thang Q. Nguyen wrote: >> From: Thang Nguyen >> >> As per USB 2.0 link power management addendum ECN, table 1-2, page 4, >> device or host initiated via resume signaling; device-initiated resumes >>

Re: [PATCH] x86/kbuild: enable modversions for symbols exported from asm

On Sat, 10 Dec 2016 13:41:03 +0100 Greg Kroah-Hartman wrote: > On Fri, Dec 09, 2016 at 11:46:54PM +0100, Dodji Seketeli wrote: > > Hello, > > > > Nicholas Piggin a écrit: > > > > [...] > > > > > That said, a dwarf based checker tool should be

Re: [PATCH] x86/kbuild: enable modversions for symbols exported from asm

On Sat, 10 Dec 2016 13:41:03 +0100 Greg Kroah-Hartman wrote: > On Fri, Dec 09, 2016 at 11:46:54PM +0100, Dodji Seketeli wrote: > > Hello, > > > > Nicholas Piggin a écrit: > > > > [...] > > > > > That said, a dwarf based checker tool should be able to do as good a job > > > (maybe a bit

[PATCH v2] siphash: add cryptographically secure hashtable function

SipHash is a 64-bit keyed hash function that is actually a cryptographically secure PRF, like HMAC. Except SipHash is super fast, and is meant to be used as a hashtable keyed lookup function. SipHash isn't just some new trendy hash function. It's been around for a while, and there really isn't

[PATCH v2] siphash: add cryptographically secure hashtable function

SipHash is a 64-bit keyed hash function that is actually a cryptographically secure PRF, like HMAC. Except SipHash is super fast, and is meant to be used as a hashtable keyed lookup function. SipHash isn't just some new trendy hash function. It's been around for a while, and there really isn't

Re: [PATCH] Fix multiple definition error under lto

On Sat, 2016-11-26 at 17:25 -0500, Peter Foley wrote: > drivers/thermal/built-in.o: In function `type_show.lto_priv.33': > (.text+0x3d80): multiple definition of `type_show.lto_priv.33' > drivers/base/built-in.o:(.text+0x2a40): first defined here > can you illustrate how to reproduce this

Re: [PATCH] Fix multiple definition error under lto

On Sat, 2016-11-26 at 17:25 -0500, Peter Foley wrote: > drivers/thermal/built-in.o: In function `type_show.lto_priv.33': > (.text+0x3d80): multiple definition of `type_show.lto_priv.33' > drivers/base/built-in.o:(.text+0x2a40): first defined here > can you illustrate how to reproduce this

Re: [Ocfs2-devel] [PATCH] ocfs2: fix crash caused by stale lvb with fsdlm plugin

Hi Gang, On 12/12/2016 10:56 AM, Gang He wrote: Hi Eric, Looks good for me. Just one suggestion, please monitor if the LVB sharing mechanism in the cluster still works well in the normal scenario, to avoid any performance decrease regression problem. Thanks for your review. I have done the

Re: [Ocfs2-devel] [PATCH] ocfs2: fix crash caused by stale lvb with fsdlm plugin

Hi Gang, On 12/12/2016 10:56 AM, Gang He wrote: Hi Eric, Looks good for me. Just one suggestion, please monitor if the LVB sharing mechanism in the cluster still works well in the normal scenario, to avoid any performance decrease regression problem. Thanks for your review. I have done the

Re: [PATCH] arm64: mm: Fix NOMAP page initialization

hi Robert, On 2016/12/10 2:10, Robert Richter wrote: > On ThunderX systems with certain memory configurations we see the > following BUG_ON(): > > kernel BUG at mm/page_alloc.c:1848! > > This happens for some configs with 64k page size enabled. The BUG_ON() > checks if start and end page of a

Re: [PATCH] arm64: mm: Fix NOMAP page initialization

hi Robert, On 2016/12/10 2:10, Robert Richter wrote: > On ThunderX systems with certain memory configurations we see the > following BUG_ON(): > > kernel BUG at mm/page_alloc.c:1848! > > This happens for some configs with 64k page size enabled. The BUG_ON() > checks if start and end page of a

[V2] mtd: devices: docg3:- Handle return value of devm_ioremap.

Here, If devm_ioremap will fail. It will return NULL. Kernel can run into a NULL-pointer dereference. Signed-off-by: Arvind Yadav --- drivers/mtd/devices/docg3.c | 7 ++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/drivers/mtd/devices/docg3.c

[V2] mtd: devices: docg3:- Handle return value of devm_ioremap.

Here, If devm_ioremap will fail. It will return NULL. Kernel can run into a NULL-pointer dereference. Signed-off-by: Arvind Yadav --- drivers/mtd/devices/docg3.c | 7 ++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/drivers/mtd/devices/docg3.c b/drivers/mtd/devices/docg3.c

Re: [V1] mtd: devices: docg3:- Handle return value of devm_ioremap.

Yes, We are returning -ENOMEM, ret is initialized to -ENOMEM. As per your concern, I have added dev_err failure message. Thanks -Arvind On Monday 12 December 2016 12:45 AM, Marek Vasut wrote: On 12/11/2016 07:01 PM, Arvind Yadav wrote: Here, If devm_ioremap will fail. It will return NULL.

Re: [V1] mtd: devices: docg3:- Handle return value of devm_ioremap.

Yes, We are returning -ENOMEM, ret is initialized to -ENOMEM. As per your concern, I have added dev_err failure message. Thanks -Arvind On Monday 12 December 2016 12:45 AM, Marek Vasut wrote: On 12/11/2016 07:01 PM, Arvind Yadav wrote: Here, If devm_ioremap will fail. It will return NULL.

Re: [PATCH] ocfs2: fix crash caused by stale lvb with fsdlm plugin

Hi Eric, Looks good for me. Just one suggestion, please monitor if the LVB sharing mechanism in the cluster still works well in the normal scenario, to avoid any performance decrease regression problem. Reviewed-by: Gang He Thanks Gang >>> > The crash happens rather often

Re: [PATCH] ocfs2: fix crash caused by stale lvb with fsdlm plugin

Hi Eric, Looks good for me. Just one suggestion, please monitor if the LVB sharing mechanism in the cluster still works well in the normal scenario, to avoid any performance decrease regression problem. Reviewed-by: Gang He Thanks Gang >>> > The crash happens rather often when we reset

Re: [PATCH v2 1/1] lockd: Change nsm_use_hostnames from bool to u32

Hi Xinhui Thanks, it really works. Will send out V3 soon afterwards B.R. Jia On 12/12/16 1:43 AM, Pan Xinhui wrote: hi, jia nice catch! However I think we should fix it totally. This is because do_proc_dointvec_conv() try to get a int value from a bool *. something like below might

Re: [PATCH v2 1/1] lockd: Change nsm_use_hostnames from bool to u32

Hi Xinhui Thanks, it really works. Will send out V3 soon afterwards B.R. Jia On 12/12/16 1:43 AM, Pan Xinhui wrote: hi, jia nice catch! However I think we should fix it totally. This is because do_proc_dointvec_conv() try to get a int value from a bool *. something like below might

Re: [PATCH v2 2/2] x86/KASLR/64: Determine kernel text mapping size at runtime

On 12/11/16 at 01:06pm, Borislav Petkov wrote: > On Sun, Dec 11, 2016 at 06:58:29PM +0800, Baoquan He wrote: > > For arguing and defending myself, I couldn't be very objective. > > Yeah, it is mind-boggling the amount of bullshit you would come up with > instead of simply saying, "no, I don't

Re: [PATCH v2 2/2] x86/KASLR/64: Determine kernel text mapping size at runtime

On 12/11/16 at 01:06pm, Borislav Petkov wrote: > On Sun, Dec 11, 2016 at 06:58:29PM +0800, Baoquan He wrote: > > For arguing and defending myself, I couldn't be very objective. > > Yeah, it is mind-boggling the amount of bullshit you would come up with > instead of simply saying, "no, I don't

  1   2   3   4   >