Re: [PATCH 37/45] drivers: use req op accessor

On 08/03/2016 07:30 PM, Shaun Tancheff wrote: > On Wed, Aug 3, 2016 at 6:47 PM, Mike Christie wrote: >> On 08/03/2016 05:33 PM, Ross Zwisler wrote: >>> On Sun, Jun 5, 2016 at 1:32 PM, wrote: From: Mike Christie The

Re: [PATCH 37/45] drivers: use req op accessor

On 08/03/2016 07:30 PM, Shaun Tancheff wrote: > On Wed, Aug 3, 2016 at 6:47 PM, Mike Christie wrote: >> On 08/03/2016 05:33 PM, Ross Zwisler wrote: >>> On Sun, Jun 5, 2016 at 1:32 PM, wrote: From: Mike Christie The req operation REQ_OP is separated from the rq_flag_bits

Re: [PATCH v3] virtio_blk: Fix a slient kernel panic

Hi, Michael. Since Stefan and Cornelia have review-acked this patch, could you mind helping review this patch? Thanks Minfei > On Jul 29, 2016, at 16:26, Stefan Hajnoczi wrote: > > On Tue, Jul 19, 2016 at 5:32 AM, Minfei Huang wrote: >> From: Minfei

Re: [PATCH v3] virtio_blk: Fix a slient kernel panic

Hi, Michael. Since Stefan and Cornelia have review-acked this patch, could you mind helping review this patch? Thanks Minfei > On Jul 29, 2016, at 16:26, Stefan Hajnoczi wrote: > > On Tue, Jul 19, 2016 at 5:32 AM, Minfei Huang wrote: >> From: Minfei Huang >> >> We do a lot of memory

Re: [PATCH] iio: humidity: hdc100x: use i2c_master_recv to read sensor data

> > Replace the i2c_smbus_read_byte commmands used to retrieve the sensor > > data with an i2c_master_recv command. > > > > The smbus read byte method fails because the device does not expect a > > stop condition after sending the first byte. When we issue the second > > read, we are getting the

Re: [PATCH] iio: humidity: hdc100x: use i2c_master_recv to read sensor data

> > Replace the i2c_smbus_read_byte commmands used to retrieve the sensor > > data with an i2c_master_recv command. > > > > The smbus read byte method fails because the device does not expect a > > stop condition after sending the first byte. When we issue the second > > read, we are getting the

[patch] CRIS v32: remove some double unlocks

We unlocked a few lines earlier so we can delete these unlocks. Signed-off-by: Dan Carpenter diff --git a/arch/cris/arch-v32/mach-a3/dma.c b/arch/cris/arch-v32/mach-a3/dma.c index 47c64bf..11f417f 100644 --- a/arch/cris/arch-v32/mach-a3/dma.c +++

[patch] CRIS v32: remove some double unlocks

We unlocked a few lines earlier so we can delete these unlocks. Signed-off-by: Dan Carpenter diff --git a/arch/cris/arch-v32/mach-a3/dma.c b/arch/cris/arch-v32/mach-a3/dma.c index 47c64bf..11f417f 100644 --- a/arch/cris/arch-v32/mach-a3/dma.c +++ b/arch/cris/arch-v32/mach-a3/dma.c @@ -41,7

[patch] mailbox: bcm-pdc: potential NULL dereference in pdc_shutdown()

We can't pass NULL pointers to pdc_ring_free() so I moved the check for NULL. Signed-off-by: Dan Carpenter diff --git a/drivers/mailbox/bcm-pdc-mailbox.c b/drivers/mailbox/bcm-pdc-mailbox.c index cbe0c1e..c56d4d0 100644 --- a/drivers/mailbox/bcm-pdc-mailbox.c +++

[patch] mailbox: bcm-pdc: potential NULL dereference in pdc_shutdown()

We can't pass NULL pointers to pdc_ring_free() so I moved the check for NULL. Signed-off-by: Dan Carpenter diff --git a/drivers/mailbox/bcm-pdc-mailbox.c b/drivers/mailbox/bcm-pdc-mailbox.c index cbe0c1e..c56d4d0 100644 --- a/drivers/mailbox/bcm-pdc-mailbox.c +++

Re: [RFC][PATCH 3/4] power: reset: Add sram-reboot-mode driver

On Wed 03 Aug 20:08 PDT 2016, John Stultz wrote: > On Wed, Aug 3, 2016 at 6:03 PM, Bjorn Andersson > wrote: > > On Wed 03 Aug 16:05 PDT 2016, John Stultz wrote: > > > > [..] > >> diff --git a/drivers/power/reset/sram-reboot-mode.c > >>

Re: [RFC][PATCH 3/4] power: reset: Add sram-reboot-mode driver

On Wed 03 Aug 20:08 PDT 2016, John Stultz wrote: > On Wed, Aug 3, 2016 at 6:03 PM, Bjorn Andersson > wrote: > > On Wed 03 Aug 16:05 PDT 2016, John Stultz wrote: > > > > [..] > >> diff --git a/drivers/power/reset/sram-reboot-mode.c > >> b/drivers/power/reset/sram-reboot-mode.c [..] > >> +

[patch] rapidio: dereferencing an error pointer

If riocm_ch_alloc() fails then we end up dereferencing the error pointer. The problem is that we're not unwinding in the reverse order from how we allocate things so it gets confusing. I've changed this around so now "ch" is NULL when we are done with it after we call riocm_put_channel(). That

[patch] rapidio: dereferencing an error pointer

If riocm_ch_alloc() fails then we end up dereferencing the error pointer. The problem is that we're not unwinding in the reverse order from how we allocate things so it gets confusing. I've changed this around so now "ch" is NULL when we are done with it after we call riocm_put_channel(). That

[patch] mfd: 88pm80x: Double shifting bug in suspend/resume

set_bit() and clear_bit() take the bit number so this code is really doing "1 << (1 << irq)" which is a double shift bug. It's done consistently so it won't cause a problem unless "irq" is more than 4. Fixes: 70c6cce04066 ('mfd: Support 88pm80x in 80x driver') Signed-off-by: Dan Carpenter

[patch] mfd: 88pm80x: Double shifting bug in suspend/resume

set_bit() and clear_bit() take the bit number so this code is really doing "1 << (1 << irq)" which is a double shift bug. It's done consistently so it won't cause a problem unless "irq" is more than 4. Fixes: 70c6cce04066 ('mfd: Support 88pm80x in 80x driver') Signed-off-by: Dan Carpenter diff

Re: "run seccomp after ptrace" changes expose "missing PTRACE_EVENT_EXIT" bug

On Wed, Aug 3, 2016 at 4:51 PM, Robert O'Callahan wrote: > I work on rr (http://rr-project.org/), a record-and-replay reverse-execution > debugger which is a heavy user of ptrace and seccomp. The recent change to > perform syscall-entry PTRACE_SYSCALL stops before

Re: "run seccomp after ptrace" changes expose "missing PTRACE_EVENT_EXIT" bug

On Wed, Aug 3, 2016 at 4:51 PM, Robert O'Callahan wrote: > I work on rr (http://rr-project.org/), a record-and-replay reverse-execution > debugger which is a heavy user of ptrace and seccomp. The recent change to > perform syscall-entry PTRACE_SYSCALL stops before PTRACE_EVENT_SECCOMP stops >

Re: [GIT PULL] Thermal SoC management updates for v4.8-rc1

On 三, 2016-08-03 at 16:26 -0700, Eduardo Valentin wrote: > On Wed, Aug 03, 2016 at 03:58:47PM -0700, Eduardo Valentin wrote: > > > > Hello Rui, > > > > Please pull from > So, forgot to mention that I have been away from upstream work for > some > time now, and I am still catching up on my

Re: [GIT PULL] Thermal SoC management updates for v4.8-rc1

On 三, 2016-08-03 at 16:26 -0700, Eduardo Valentin wrote: > On Wed, Aug 03, 2016 at 03:58:47PM -0700, Eduardo Valentin wrote: > > > > Hello Rui, > > > > Please pull from > So, forgot to mention that I have been away from upstream work for > some > time now, and I am still catching up on my

[PATCH] .mailmap: Correct entries for Mauro Carvalho Chehab and Shuah Khan

mailmap entries may not use more than 2 email addresses per line. Signed-off-by: Joe Perches --- .mailmap | 13 +++-- 1 file changed, 11 insertions(+), 2 deletions(-) diff --git a/.mailmap b/.mailmap index c0d5704..2a91c14c 100644 --- a/.mailmap +++ b/.mailmap @@

[PATCH] .mailmap: Correct entries for Mauro Carvalho Chehab and Shuah Khan

mailmap entries may not use more than 2 email addresses per line. Signed-off-by: Joe Perches --- .mailmap | 13 +++-- 1 file changed, 11 insertions(+), 2 deletions(-) diff --git a/.mailmap b/.mailmap index c0d5704..2a91c14c 100644 --- a/.mailmap +++ b/.mailmap @@ -96,7 +96,13 @@ Linus

RE: Kernel panics while creating RAID volume on latest stable 4.6.2 kernel beacuse of "[PATCH v2 3/3] ses: fix discovery of SATA devices in SAS enclosures"

Any updates on this ??? Thanks, Chaitra -Original Message- From: Chaitra Basappa [mailto:chaitra.basa...@broadcom.com] Sent: Friday, June 17, 2016 4:04 PM To: linux-kernel@vger.kernel.org; Linux SCSI Mailinglist; James Bottomley Subject: Kernel panics while creating RAID volume on

RE: Kernel panics while creating RAID volume on latest stable 4.6.2 kernel beacuse of "[PATCH v2 3/3] ses: fix discovery of SATA devices in SAS enclosures"

Any updates on this ??? Thanks, Chaitra -Original Message- From: Chaitra Basappa [mailto:chaitra.basa...@broadcom.com] Sent: Friday, June 17, 2016 4:04 PM To: linux-kernel@vger.kernel.org; Linux SCSI Mailinglist; James Bottomley Subject: Kernel panics while creating RAID volume on

[PATCH 2/2] power: reset: syscon-reboot-mode: Use managed resource API

Use the managed resource version of reboot_mode_register(). Cc: John Stultz Signed-off-by: Bjorn Andersson --- John, here's a "pointer" to what I meant with my comment on your sram-reboot-mode patch. Only compile tested though.

[bug, 4.8] /proc/meminfo: counter values are very wrong

Hi folks, I just noticed a whacky memory usage profile when running some basic IO tests on a current 4.8 tree. It looked like there was a massive memory leak from my monitoring graphs - doing buffered IO was causing huge amounts of memory to be considered used, but the cache size was not

[PATCH 2/2] power: reset: syscon-reboot-mode: Use managed resource API

Use the managed resource version of reboot_mode_register(). Cc: John Stultz Signed-off-by: Bjorn Andersson --- John, here's a "pointer" to what I meant with my comment on your sram-reboot-mode patch. Only compile tested though. drivers/power/reset/syscon-reboot-mode.c | 12 +--- 1

[bug, 4.8] /proc/meminfo: counter values are very wrong

Hi folks, I just noticed a whacky memory usage profile when running some basic IO tests on a current 4.8 tree. It looked like there was a massive memory leak from my monitoring graphs - doing buffered IO was causing huge amounts of memory to be considered used, but the cache size was not

[PATCH 1/2] power: reset: reboot-mode: Add managed resource API

Provide managed resource version of reboot_mode_register() and reboot_mode_unregister() to simplify implementations. Cc: John Stultz Signed-off-by: Bjorn Andersson --- John, here's a "pointer" to what I meant with my comment on your

Re: [RFC PATCH v7 1/7] Restartable sequences system call

On Wed, Aug 3, 2016 at 9:27 PM, Boqun Feng wrote: > On Wed, Aug 03, 2016 at 09:37:57AM -0700, Andy Lutomirski wrote: >> On Wed, Aug 3, 2016 at 5:27 AM, Peter Zijlstra wrote: >> > On Tue, Jul 26, 2016 at 03:02:19AM +, Mathieu Desnoyers wrote: >> >>

[PATCH 1/2] power: reset: reboot-mode: Add managed resource API

Provide managed resource version of reboot_mode_register() and reboot_mode_unregister() to simplify implementations. Cc: John Stultz Signed-off-by: Bjorn Andersson --- John, here's a "pointer" to what I meant with my comment on your sram-reboot-mode patch. Only compile tested though.

Re: [RFC PATCH v7 1/7] Restartable sequences system call

On Wed, Aug 3, 2016 at 9:27 PM, Boqun Feng wrote: > On Wed, Aug 03, 2016 at 09:37:57AM -0700, Andy Lutomirski wrote: >> On Wed, Aug 3, 2016 at 5:27 AM, Peter Zijlstra wrote: >> > On Tue, Jul 26, 2016 at 03:02:19AM +, Mathieu Desnoyers wrote: >> >> We really care about preemption here. Every

Re: [RFC PATCH v7 1/7] Restartable sequences system call

On Aug 3, 2016 11:31 AM, "Christoph Lameter" wrote: > > On Wed, 3 Aug 2016, Andy Lutomirski wrote: > > > > Well, a CMPXCHG without LOCK prefix isn't all that expensive on x86. > > > > > > It is however on PPC and possibly other architectures, so in name of > > > simplicity

Re: [RFC PATCH v7 1/7] Restartable sequences system call

On Aug 3, 2016 11:31 AM, "Christoph Lameter" wrote: > > On Wed, 3 Aug 2016, Andy Lutomirski wrote: > > > > Well, a CMPXCHG without LOCK prefix isn't all that expensive on x86. > > > > > > It is however on PPC and possibly other architectures, so in name of > > > simplicity supporting only the one

Re: [PATCH] iio: humidity: hdc100x: use i2c_master_recv to read sensor data

On Wed, Aug 3, 2016 at 8:33 PM, Alison Schofield wrote: > Replace the i2c_smbus_read_byte commmands used to retrieve the sensor > data with an i2c_master_recv command. > > The smbus read byte method fails because the device does not expect a > stop condition after sending

Re: [PATCH] iio: humidity: hdc100x: use i2c_master_recv to read sensor data

On Wed, Aug 3, 2016 at 8:33 PM, Alison Schofield wrote: > Replace the i2c_smbus_read_byte commmands used to retrieve the sensor > data with an i2c_master_recv command. > > The smbus read byte method fails because the device does not expect a > stop condition after sending the first byte. When we

Re: [PATCH v15 04/10] arm64: Kprobes with single stepping support

On 07/29/2016 05:01 AM, Daniel Thompson wrote: > On 28/07/16 15:40, Catalin Marinas wrote: >> On Wed, Jul 27, 2016 at 06:13:37PM -0400, David Long wrote: >>> On 07/27/2016 07:50 AM, Daniel Thompson wrote: On 25/07/16 23:27, David Long wrote: > On 07/25/2016 01:13 PM, Catalin Marinas

Re: [PATCH v15 04/10] arm64: Kprobes with single stepping support

On 07/29/2016 05:01 AM, Daniel Thompson wrote: > On 28/07/16 15:40, Catalin Marinas wrote: >> On Wed, Jul 27, 2016 at 06:13:37PM -0400, David Long wrote: >>> On 07/27/2016 07:50 AM, Daniel Thompson wrote: On 25/07/16 23:27, David Long wrote: > On 07/25/2016 01:13 PM, Catalin Marinas

Build error in -next due to 'sh: add working futex atomic ops on userspace addresses for smp'

Hi, I see the following build error in -next when building sh:shx3_defconfig. {standard input}: Assembler messages: {standard input}:177: Error: unknown opcode {standard input}:7760: Error: unknown opcode {standard input}:163: Error: displacement to defined symbol .L24 overflows 8-bit field

Build error in -next due to 'sh: add working futex atomic ops on userspace addresses for smp'

Hi, I see the following build error in -next when building sh:shx3_defconfig. {standard input}: Assembler messages: {standard input}:177: Error: unknown opcode {standard input}:7760: Error: unknown opcode {standard input}:163: Error: displacement to defined symbol .L24 overflows 8-bit field

[GIT PULL] target updates for v4.8-rc1

Hello Linus, Here are the target-pending updates for v4.8-rc1. Please go ahead and pull from: git://git.kernel.org/pub/scm/linux/kernel/git/nab/target-pending.git for-next The most notable item is IBM virtual SCSI target driver, that was originally ported to target-core back in 2010 by

[GIT PULL] target updates for v4.8-rc1

Hello Linus, Here are the target-pending updates for v4.8-rc1. Please go ahead and pull from: git://git.kernel.org/pub/scm/linux/kernel/git/nab/target-pending.git for-next The most notable item is IBM virtual SCSI target driver, that was originally ported to target-core back in 2010 by

[PATCH v6 2/2] clocksource: add J-Core timer/clocksource driver

At the hardware level, the J-Core PIT is integrated with the interrupt controller, but it is represented as its own device and has an independent programming interface. It provides a 12-bit countdown timer, which is not presently used, and a periodic timer. The interval length for the latter is

[PATCH v6 2/2] clocksource: add J-Core timer/clocksource driver

At the hardware level, the J-Core PIT is integrated with the interrupt controller, but it is represented as its own device and has an independent programming interface. It provides a 12-bit countdown timer, which is not presently used, and a periodic timer. The interval length for the latter is

Re: [PATCH v5 2/2] spi: add driver for J-Core SPI controller

On Wed, Aug 03, 2016 at 08:16:43AM -0500, Rob Herring wrote: > On Sun, Apr 3, 2016 at 12:12 AM, Rich Felker wrote: > > The date on your patch emails is way off. Thanks for catching this. I tweaked my email-prep scripts to improve coverage of who to send to, and somehow lost the

Re: [PATCH v5 2/2] spi: add driver for J-Core SPI controller

On Wed, Aug 03, 2016 at 08:16:43AM -0500, Rob Herring wrote: > On Sun, Apr 3, 2016 at 12:12 AM, Rich Felker wrote: > > The date on your patch emails is way off. Thanks for catching this. I tweaked my email-prep scripts to improve coverage of who to send to, and somehow lost the part that

[PATCH v5 1/2] of: add J-Core SPI master bindings

Signed-off-by: Rich Felker --- .../devicetree/bindings/spi/jcore,spi.txt | 34 ++ 1 file changed, 34 insertions(+) create mode 100644 Documentation/devicetree/bindings/spi/jcore,spi.txt diff --git

[PATCH v5 2/2] spi: add driver for J-Core SPI controller

The J-Core "spi2" device is a PIO-based SPI master controller. It differs from "bitbang" devices in that that it's clocked in hardware rather than via soft clock modulation over gpio, and performs byte-at-a-time transfers between the cpu and SPI controller. This driver will be extended to support

[PATCH v6 0/2] J-Core timer support

Updated to include changes requested by Thomas Gleixner. Aside from minor style improvements, the main changes are moving from the old cpu notifier framework for cpu starting to the cpuhotplug framework. Since the new framework does not easily facilitate multiple driver instances without

[PATCH v5 1/2] of: add J-Core SPI master bindings

Signed-off-by: Rich Felker --- .../devicetree/bindings/spi/jcore,spi.txt | 34 ++ 1 file changed, 34 insertions(+) create mode 100644 Documentation/devicetree/bindings/spi/jcore,spi.txt diff --git a/Documentation/devicetree/bindings/spi/jcore,spi.txt

[PATCH v5 2/2] spi: add driver for J-Core SPI controller

The J-Core "spi2" device is a PIO-based SPI master controller. It differs from "bitbang" devices in that that it's clocked in hardware rather than via soft clock modulation over gpio, and performs byte-at-a-time transfers between the cpu and SPI controller. This driver will be extended to support

[PATCH v6 0/2] J-Core timer support

Updated to include changes requested by Thomas Gleixner. Aside from minor style improvements, the main changes are moving from the old cpu notifier framework for cpu starting to the cpuhotplug framework. Since the new framework does not easily facilitate multiple driver instances without

[PATCH v6 1/2] of: add J-Core timer bindings

Signed-off-by: Rich Felker --- .../devicetree/bindings/timer/jcore,pit.txt| 24 ++ 1 file changed, 24 insertions(+) create mode 100644 Documentation/devicetree/bindings/timer/jcore,pit.txt diff --git

[PATCH v5 0/2] J-Core SPI controller support

Updates based on requests by Mark Brown. Driver has been made conditional in Kconfig to avoid it showing up in configurations where it's not relevant. Lots of small style improvements have been made, and the input clock frequency is now handled via the clk framework rather than a fixed

[PATCH v5 0/2] J-Core SPI controller support

Updates based on requests by Mark Brown. Driver has been made conditional in Kconfig to avoid it showing up in configurations where it's not relevant. Lots of small style improvements have been made, and the input clock frequency is now handled via the clk framework rather than a fixed

[PATCH v6 1/2] of: add J-Core timer bindings

Signed-off-by: Rich Felker --- .../devicetree/bindings/timer/jcore,pit.txt| 24 ++ 1 file changed, 24 insertions(+) create mode 100644 Documentation/devicetree/bindings/timer/jcore,pit.txt diff --git a/Documentation/devicetree/bindings/timer/jcore,pit.txt

Re: [PATCH v2 1/3] mtd: introduce the mtd_pairing_scheme concept

Hi Boris, On Mon, Jun 20, 2016 at 03:50:16PM +0200, Boris Brezillon wrote: > MLC and TLC NAND devices are using NAND cells exposing more than one bit, > but instead of attaching all the bits in a given cell to a single NAND > page, each bit is usually attached to a different page. This concept is

[PATCH v5] usb: ohci-at91: Forcibly suspend ports while USB suspend

The usb controller does not managed correctly the suspend mode for the ehci. In echi mode, there is no way to have utmi_suspend_o_n[1] suspend without any device connected to it. This is why this specific control is added to fix this issue. The suspend mode works in ohci mode. This specific

Re: [PATCH v2 1/3] mtd: introduce the mtd_pairing_scheme concept

Hi Boris, On Mon, Jun 20, 2016 at 03:50:16PM +0200, Boris Brezillon wrote: > MLC and TLC NAND devices are using NAND cells exposing more than one bit, > but instead of attaching all the bits in a given cell to a single NAND > page, each bit is usually attached to a different page. This concept is

[PATCH v5] usb: ohci-at91: Forcibly suspend ports while USB suspend

The usb controller does not managed correctly the suspend mode for the ehci. In echi mode, there is no way to have utmi_suspend_o_n[1] suspend without any device connected to it. This is why this specific control is added to fix this issue. The suspend mode works in ohci mode. This specific

[PATCH v6 2/2] irqchip: add J-Core AIC driver

There are two versions of the J-Core interrupt controller in use, aic1 which generates interrupts with programmable priorities, but only supports 8 irq lines and maps them to cpu traps in the range 17 to 24, and aic2 which uses traps in the range 64-127 and supports up to 128 irqs, with priorities

[PATCH v6 0/2] J-Core interrupt controller support

Updated based on feedback from Thomas Gleixner. Removal of unnecessary data allowed some simplification. Magic numbers have been replaced with meaningful (I hope) macro constants, comments added, and minor style issues fixed. Also, driver was made conditional in Kconfig to avoid it showing up in

[PATCH v6 1/2] of: add J-Core interrupt controller bindings

Signed-off-by: Rich Felker Acked-by: Rob Herring --- .../bindings/interrupt-controller/jcore,aic.txt| 26 ++ 1 file changed, 26 insertions(+) create mode 100644 Documentation/devicetree/bindings/interrupt-controller/jcore,aic.txt diff

[PATCH v6 0/2] J-Core interrupt controller support

Updated based on feedback from Thomas Gleixner. Removal of unnecessary data allowed some simplification. Magic numbers have been replaced with meaningful (I hope) macro constants, comments added, and minor style issues fixed. Also, driver was made conditional in Kconfig to avoid it showing up in

[PATCH v6 1/2] of: add J-Core interrupt controller bindings

Signed-off-by: Rich Felker Acked-by: Rob Herring --- .../bindings/interrupt-controller/jcore,aic.txt| 26 ++ 1 file changed, 26 insertions(+) create mode 100644 Documentation/devicetree/bindings/interrupt-controller/jcore,aic.txt diff --git

[PATCH v6 2/2] irqchip: add J-Core AIC driver

There are two versions of the J-Core interrupt controller in use, aic1 which generates interrupts with programmable priorities, but only supports 8 irq lines and maps them to cpu traps in the range 17 to 24, and aic2 which uses traps in the range 64-127 and supports up to 128 irqs, with priorities

Re: Generic section maintainers

On Wed, Aug 03, 2016 at 12:56:22PM -0700, Luis R. Rodriguez wrote: > Arnd, Josh, > > In my linker table work [0], other than the linker table work and > section ranges stuff, I'm adding: > > o include/linux/sections.h > o include/asm-generic/section-core.h (not in RFC v3 but it is in my > RFC v4

Re: Generic section maintainers

On Wed, Aug 03, 2016 at 12:56:22PM -0700, Luis R. Rodriguez wrote: > Arnd, Josh, > > In my linker table work [0], other than the linker table work and > section ranges stuff, I'm adding: > > o include/linux/sections.h > o include/asm-generic/section-core.h (not in RFC v3 but it is in my > RFC v4

Re: [RFC PATCH v7 1/7] Restartable sequences system call

On Wed, Aug 03, 2016 at 09:37:57AM -0700, Andy Lutomirski wrote: > On Wed, Aug 3, 2016 at 5:27 AM, Peter Zijlstra wrote: > > On Tue, Jul 26, 2016 at 03:02:19AM +, Mathieu Desnoyers wrote: > >> We really care about preemption here. Every migration implies a > >>

Re: [RFC PATCH v7 1/7] Restartable sequences system call

On Wed, Aug 03, 2016 at 09:37:57AM -0700, Andy Lutomirski wrote: > On Wed, Aug 3, 2016 at 5:27 AM, Peter Zijlstra wrote: > > On Tue, Jul 26, 2016 at 03:02:19AM +, Mathieu Desnoyers wrote: > >> We really care about preemption here. Every migration implies a > >> preemption from a user-space

linux-next: Tree for Aug 4

Hi all, Please do not add material destined for v4.9 to your linux-next included branches until after v4.8-rc1 has been released. Changes since 20160803: The v4l-dvb tree gained a conflict against Linus' tree. The thermal-soc tree gained a conflict against the thermal tree. Non-merge commits

linux-next: Tree for Aug 4

Hi all, Please do not add material destined for v4.9 to your linux-next included branches until after v4.8-rc1 has been released. Changes since 20160803: The v4l-dvb tree gained a conflict against Linus' tree. The thermal-soc tree gained a conflict against the thermal tree. Non-merge commits

Re: [PATCH v3 2/6] extcon: Add the support for extcon property according to extcon type

On Wed, Aug 3, 2016 at 5:42 PM, Chanwoo Choi wrote: > Hi Roger, > > On 2016년 08월 03일 18:46, Roger Quadros wrote: >> Hi Chanwoo, >> [ ... ] > + /* > + * Check whether the external connector is attached. > + * If external connector is detached, the user can

Re: [PATCH v3 2/6] extcon: Add the support for extcon property according to extcon type

On Wed, Aug 3, 2016 at 5:42 PM, Chanwoo Choi wrote: > Hi Roger, > > On 2016년 08월 03일 18:46, Roger Quadros wrote: >> Hi Chanwoo, >> [ ... ] > + /* > + * Check whether the external connector is attached. > + * If external connector is detached, the user can not > + * get

A question about transparent hugepages

according to the total_mapcount, Different process can map any subpages of the transparent hugepages. How it can happen to ?

A question about transparent hugepages

according to the total_mapcount, Different process can map any subpages of the transparent hugepages. How it can happen to ?

Re: [PATCH v2] powerpc/32: fix csum_partial_copy_generic()

On Tue, 2016-08-02 at 10:07 +0200, Christophe Leroy wrote: > commit 7aef4136566b0 ("powerpc32: rewrite csum_partial_copy_generic() > based on copy_tofrom_user()") introduced a bug when destination > address is odd and initial csum is not null > > In that (rare) case the initial csum value has to

Re: [PATCH v2] powerpc/32: fix csum_partial_copy_generic()

On Tue, 2016-08-02 at 10:07 +0200, Christophe Leroy wrote: > commit 7aef4136566b0 ("powerpc32: rewrite csum_partial_copy_generic() > based on copy_tofrom_user()") introduced a bug when destination > address is odd and initial csum is not null > > In that (rare) case the initial csum value has to

RE: [PATCH] usb: ohci-at91: Suspend the ports while USB suspending

Hi Alan, From: Alan Stern [st...@rowland.harvard.edu] Sent: Friday, May 13, 2016 2:11 To: Yang, Wenyou Cc: Greg Kroah-Hartman; Ferre, Nicolas; linux-...@vger.kernel.org; linux-kernel@vger.kernel.org; linux-arm-ker...@lists.infradead.org Subject: Re:

RE: [PATCH] usb: ohci-at91: Suspend the ports while USB suspending

Hi Alan, From: Alan Stern [st...@rowland.harvard.edu] Sent: Friday, May 13, 2016 2:11 To: Yang, Wenyou Cc: Greg Kroah-Hartman; Ferre, Nicolas; linux-...@vger.kernel.org; linux-kernel@vger.kernel.org; linux-arm-ker...@lists.infradead.org Subject: Re:

Re: [RFC PATCH v2 1/4] Documentation: DT: net: Add Xilinx gmiitorgmii converter device tree binding documentation

On 27/07/2016 01:05, Andrew Lunn wrote: > Hi Appana > > Here is roughly what i was thinking: > > struct priv { >phy_device *master; >phy_device *slave; >struct phy_driver *slave_drv; > }; > > phy_status_clone(phy_device *master, phy_device *slave) > { >

Re: [RFC PATCH v2 1/4] Documentation: DT: net: Add Xilinx gmiitorgmii converter device tree binding documentation

On 27/07/2016 01:05, Andrew Lunn wrote: > Hi Appana > > Here is roughly what i was thinking: > > struct priv { >phy_device *master; >phy_device *slave; >struct phy_driver *slave_drv; > }; > > phy_status_clone(phy_device *master, phy_device *slave) > { >

Re: [kernel-hardening] Re: [PATCH 1/2] security, perf: allow further restriction of perf_event_open

Peter Zijlstra writes: > On Wed, Aug 03, 2016 at 11:53:41AM -0700, Kees Cook wrote: >> > Kees Cook writes: >> > >> >> On Tue, Aug 2, 2016 at 1:30 PM, Peter Zijlstra >> >> wrote: >> >> Let me take this another way instead. What

Re: [kernel-hardening] Re: [PATCH 1/2] security, perf: allow further restriction of perf_event_open

Peter Zijlstra writes: > On Wed, Aug 03, 2016 at 11:53:41AM -0700, Kees Cook wrote: >> > Kees Cook writes: >> > >> >> On Tue, Aug 2, 2016 at 1:30 PM, Peter Zijlstra >> >> wrote: >> >> Let me take this another way instead. What would be a better way to >> >> provide a mechanism for system

Re: [PATCH v1] net: phy: micrel: Add specific suspend

On 03/08/2016 17:21, Wenyou Yang wrote: > Disable all interrupts when suspend, they will be enabled > when resume. Otherwise, the suspend/resume process will be > blocked occasionally. This seems like something fairly generic actually, we could imagine having the core library do something like

Re: [PATCH v1] net: phy: micrel: Add specific suspend

On 03/08/2016 17:21, Wenyou Yang wrote: > Disable all interrupts when suspend, they will be enabled > when resume. Otherwise, the suspend/resume process will be > blocked occasionally. This seems like something fairly generic actually, we could imagine having the core library do something like

Re: [PATCH v2 1/3] mm: memcontrol: fix swap counter leak on swapout from offline cgroup

On Wed, Aug 03, 2016 at 01:09:42PM +0200, Michal Hocko wrote: > On Wed 03-08-16 12:50:49, Vladimir Davydov wrote: > > On Tue, Aug 02, 2016 at 06:00:26PM +0200, Michal Hocko wrote: > > > On Tue 02-08-16 18:00:48, Vladimir Davydov wrote: > > ... > > > > diff --git a/mm/memcontrol.c b/mm/memcontrol.c

[PATCH] iio: humidity: hdc100x: use i2c_master_recv to read sensor data

Replace the i2c_smbus_read_byte commmands used to retrieve the sensor data with an i2c_master_recv command. The smbus read byte method fails because the device does not expect a stop condition after sending the first byte. When we issue the second read, we are getting the first byte again. Net

Re: [PATCH v2 1/3] mm: memcontrol: fix swap counter leak on swapout from offline cgroup

On Wed, Aug 03, 2016 at 01:09:42PM +0200, Michal Hocko wrote: > On Wed 03-08-16 12:50:49, Vladimir Davydov wrote: > > On Tue, Aug 02, 2016 at 06:00:26PM +0200, Michal Hocko wrote: > > > On Tue 02-08-16 18:00:48, Vladimir Davydov wrote: > > ... > > > > diff --git a/mm/memcontrol.c b/mm/memcontrol.c

[PATCH] iio: humidity: hdc100x: use i2c_master_recv to read sensor data

Replace the i2c_smbus_read_byte commmands used to retrieve the sensor data with an i2c_master_recv command. The smbus read byte method fails because the device does not expect a stop condition after sending the first byte. When we issue the second read, we are getting the first byte again. Net

Re: [PATCH] powerpc: move hmi.c to arch/powerpc/kvm/

Paolo Bonzini writes: > hmi.c functions are unused unless sibling_subcore_state is nonzero, and > that in turn happens only if KVM is in use. So move the code to > arch/powerpc/kvm/, putting it under CONFIG_KVM_BOOK3S_64_HANDLER > rather than CONFIG_PPC_BOOK3S_64. The

Re: [PATCH] powerpc: move hmi.c to arch/powerpc/kvm/

Paolo Bonzini writes: > hmi.c functions are unused unless sibling_subcore_state is nonzero, and > that in turn happens only if KVM is in use. So move the code to > arch/powerpc/kvm/, putting it under CONFIG_KVM_BOOK3S_64_HANDLER > rather than CONFIG_PPC_BOOK3S_64. The sibling_subcore_state is

Re: [RFC PATCH v2 0/3] perf/tracefs: Container-aware tracing support

Hari Bathini writes: > This RFC patch set supports filtering container specific events > when perf tool is executed inside a container. The patches apply > cleanly on v4.7.0-rc7 > > Changes from v1: > 1/3. Revived earlier approach[1] with cgroup namespace instead >

Re: [RFC PATCH v2 0/3] perf/tracefs: Container-aware tracing support

Hari Bathini writes: > This RFC patch set supports filtering container specific events > when perf tool is executed inside a container. The patches apply > cleanly on v4.7.0-rc7 > > Changes from v1: > 1/3. Revived earlier approach[1] with cgroup namespace instead > of pid namespace > 2/3.

Re: [RFC][PATCH 3/4] power: reset: Add sram-reboot-mode driver

On Wed, Aug 3, 2016 at 6:03 PM, Bjorn Andersson wrote: > On Wed 03 Aug 16:05 PDT 2016, John Stultz wrote: > > [..] >> diff --git a/drivers/power/reset/sram-reboot-mode.c >> b/drivers/power/reset/sram-reboot-mode.c > [..] >> + >> +struct sram_reboot_mode { >> +

xfstests xfs fuzzers fail with DAX

Hi, A few xfs fuzzers in xfstests fail with dax mount option, pass without dax. They are xfs/086 xfs/088 xfs/089 xfs/091. xfstests to commit 4470ad4c7e (Jul 26) kernel to commit dd95069545 (Jul 24) + ./check xfs/091 FSTYP -- xfs (non-debug) PLATFORM -- Linux/x86_64 rhel73

[PATCH v2 7/7] drm/mediatek: Fix mtk_atomic_complete for runtime_pm

To properly implement atomic w/ runtime pm, we move drm_atomic_helper_commit_modeset_enables() above drm_atomic_helper_commit_planes() to ensure CRTCs are enabled before modifying plane registers, and set active_only to true to filter out plane update notifications when the CRTC is disabled.

[PATCH v2 2/7] drm/mediatek: plane: Remove plane zpos/index

From: Daniel Kurtz It is not actually useful to a mtk plane to know its zpos/index, so just remove this field. This let's completely remove struct mtk_drm_plane in a follow up patch. Signed-off-by: Daniel Kurtz Signed-off-by: Bibby Hsieh

Re: [RFC][PATCH 3/4] power: reset: Add sram-reboot-mode driver

On Wed, Aug 3, 2016 at 6:03 PM, Bjorn Andersson wrote: > On Wed 03 Aug 16:05 PDT 2016, John Stultz wrote: > > [..] >> diff --git a/drivers/power/reset/sram-reboot-mode.c >> b/drivers/power/reset/sram-reboot-mode.c > [..] >> + >> +struct sram_reboot_mode { >> + struct reboot_mode_driver

xfstests xfs fuzzers fail with DAX

Hi, A few xfs fuzzers in xfstests fail with dax mount option, pass without dax. They are xfs/086 xfs/088 xfs/089 xfs/091. xfstests to commit 4470ad4c7e (Jul 26) kernel to commit dd95069545 (Jul 24) + ./check xfs/091 FSTYP -- xfs (non-debug) PLATFORM -- Linux/x86_64 rhel73

  1   2   3   4   5   6   7   8   9   10   >