[PATCH v2 1/4] staging : comedi : fix type issues in s626.c

This is a patch to the s626.c file that fixes up a type issues like i.e Prefer kernel type 'u8' over 'uint8_t' Prefer kernel type 'u16' over 'uint16_t' Prefer kernel type 'u32' over 'uint32_t' Prefer kernel type 's16' over 'int16_t' Prefer kernel type 's32' over 'int32_t' found by

[PATCH v2 1/4] staging : comedi : fix type issues in s626.c

This is a patch to the s626.c file that fixes up a type issues like i.e Prefer kernel type 'u8' over 'uint8_t' Prefer kernel type 'u16' over 'uint16_t' Prefer kernel type 'u32' over 'uint32_t' Prefer kernel type 's16' over 'int16_t' Prefer kernel type 's32' over 'int32_t' found by

[PATCH v2 3/4] Staging: comedi:Fix unsigned int to bare use of unsigned issue in s626.c

This is a patch to the s626.c file that fixes up a WARNING: Prefer 'unsigned int' to bare use of 'unsigned' found by the checkpatch.pl tool Signed-off-by: Ravishankar Karkala Mallikarjunayya --- changes since v1: No change --- drivers/staging/comedi/drivers/s626.c | 8

[PATCH v2 2/4] Staging: comedi: Fix WARNING issue in s626.c

This is a patch to the s626.c file that fixes up a Block comments issues found by the checkpatch.pl tool. i.e. Block comments use a trailing */ on a separate line Signed-off-by: Ravishankar Karkala Mallikarjunayya --- changes since v1: No change ---

[PATCH v2 4/4] Staging: comedi: fix line over 80 characters issue in s626.c

This is a patch to the s626.c file that fixes up a line over 80 characters issues found by the checkpatch.pl tool. Signed-off-by: Ravishankar Karkala Mallikarjunayya --- changes since v1: No change --- drivers/staging/comedi/drivers/s626.c | 3 ++- 1 file changed, 2

[PATCH v2 3/4] Staging: comedi:Fix unsigned int to bare use of unsigned issue in s626.c

This is a patch to the s626.c file that fixes up a WARNING: Prefer 'unsigned int' to bare use of 'unsigned' found by the checkpatch.pl tool Signed-off-by: Ravishankar Karkala Mallikarjunayya --- changes since v1: No change --- drivers/staging/comedi/drivers/s626.c | 8 1 file changed,

[PATCH v2 2/4] Staging: comedi: Fix WARNING issue in s626.c

This is a patch to the s626.c file that fixes up a Block comments issues found by the checkpatch.pl tool. i.e. Block comments use a trailing */ on a separate line Signed-off-by: Ravishankar Karkala Mallikarjunayya --- changes since v1: No change --- drivers/staging/comedi/drivers/s626.c | 60

[PATCH v2 4/4] Staging: comedi: fix line over 80 characters issue in s626.c

This is a patch to the s626.c file that fixes up a line over 80 characters issues found by the checkpatch.pl tool. Signed-off-by: Ravishankar Karkala Mallikarjunayya --- changes since v1: No change --- drivers/staging/comedi/drivers/s626.c | 3 ++- 1 file changed, 2 insertions(+), 1

Re: [PATCH v4 0/2] cgroup: allow management of subtrees by new cgroup namespaces

Hi Tejun, >> > Unfortunately, cgroup hierarchy isn't designed to support this sort >> > of automatic delegation. Unpriv processes would be able to escape >> > constraints on v1 with some controllers and on v2 controllers have to >> > be explicitly enabled by root for delegated scope to have

Re: [PATCH v4 0/2] cgroup: allow management of subtrees by new cgroup namespaces

Hi Tejun, >> > Unfortunately, cgroup hierarchy isn't designed to support this sort >> > of automatic delegation. Unpriv processes would be able to escape >> > constraints on v1 with some controllers and on v2 controllers have to >> > be explicitly enabled by root for delegated scope to have

[patch] IB/hfi1: fix some indenting

That extra tabs are misleading. Signed-off-by: Dan Carpenter diff --git a/drivers/infiniband/hw/hfi1/init.c b/drivers/infiniband/hw/hfi1/init.c index 5cc492e..0d28a5a 100644 --- a/drivers/infiniband/hw/hfi1/init.c +++ b/drivers/infiniband/hw/hfi1/init.c @@ -1337,7

[patch] IB/hfi1: fix some indenting

That extra tabs are misleading. Signed-off-by: Dan Carpenter diff --git a/drivers/infiniband/hw/hfi1/init.c b/drivers/infiniband/hw/hfi1/init.c index 5cc492e..0d28a5a 100644 --- a/drivers/infiniband/hw/hfi1/init.c +++ b/drivers/infiniband/hw/hfi1/init.c @@ -1337,7 +1337,7 @@ static void

[patch v2] usb: f_fs: off by one bug in _ffs_func_bind()

This loop is supposed to set all the .num[] values to -1 but it's off by one so it skips the first element and sets one element past the end of the array. I've cleaned up the loop a little as well. Fixes: ddf8abd25994 ('USB: f_fs: the FunctionFS driver') Signed-off-by: Dan Carpenter

[patch v2] usb: f_fs: off by one bug in _ffs_func_bind()

This loop is supposed to set all the .num[] values to -1 but it's off by one so it skips the first element and sets one element past the end of the array. I've cleaned up the loop a little as well. Fixes: ddf8abd25994 ('USB: f_fs: the FunctionFS driver') Signed-off-by: Dan Carpenter --- v2:

IOV iterator bug in net tree (was Re: Deadlock when running DevStack on latest pull of net tree)

On Fri, May 27, 2016 at 11:21 AM, Alexander Duyck wrote: > I started out this morning by trying to run DevStack on the latest > "net' kernel and it looks like I am hanging on some sort of locking > problem with RabbitMQ. Specifically I am seeing one CPU jump to 100% >

IOV iterator bug in net tree (was Re: Deadlock when running DevStack on latest pull of net tree)

On Fri, May 27, 2016 at 11:21 AM, Alexander Duyck wrote: > I started out this morning by trying to run DevStack on the latest > "net' kernel and it looks like I am hanging on some sort of locking > problem with RabbitMQ. Specifically I am seeing one CPU jump to 100% > with perf showing that I am

Re: linux-next memleak after IO on dax mountpoint

On Fri, May 27, 2016 at 04:46:17PM +0800, Xiong Zhou wrote: ... > Still working on to id which commit in this merge causes this issuer, Narrowed down to: 37e5823 block: add offset in blk_add_request_payload() e048948 blk-mq: Export tagset iter function 58b4560 nvme: add helper nvme_map_len()

Re: linux-next memleak after IO on dax mountpoint

On Fri, May 27, 2016 at 04:46:17PM +0800, Xiong Zhou wrote: ... > Still working on to id which commit in this merge causes this issuer, Narrowed down to: 37e5823 block: add offset in blk_add_request_payload() e048948 blk-mq: Export tagset iter function 58b4560 nvme: add helper nvme_map_len()

Re: [PATCH] pv-qspinlock: Try to re-hash the lock after spurious_wakeup

On 05/27/2016 06:32 AM, xinhui wrote: On 2016年05月27日 02:31, Waiman Long wrote: On 05/25/2016 02:09 AM, Pan Xinhui wrote: In pv_wait_head_or_lock, if there is a spurious_wakeup, and it fails to get the lock as there is lock stealing, then after a short spin, we need hash the lock again and

Re: [PATCH] pv-qspinlock: Try to re-hash the lock after spurious_wakeup

On 05/27/2016 06:32 AM, xinhui wrote: On 2016年05月27日 02:31, Waiman Long wrote: On 05/25/2016 02:09 AM, Pan Xinhui wrote: In pv_wait_head_or_lock, if there is a spurious_wakeup, and it fails to get the lock as there is lock stealing, then after a short spin, we need hash the lock again and

Re: [RFC v2 00/13] usb/mmc/power: Fix USB/LAN when TFTP booting

On Tue, May 10, 2016 at 01:02:08PM +0200, Ulf Hansson wrote: > + Arnd > > [...] > > >> >> Solution > >> >> > >> >> This is very similar to the MMC pwrseq behavior so the idea is to: > >> >> 1. Move MMC pwrseq drivers to generic place, > >> > > >> > You can do that, but I'm going to NAK

Re: [RFC v2 00/13] usb/mmc/power: Fix USB/LAN when TFTP booting

On Tue, May 10, 2016 at 01:02:08PM +0200, Ulf Hansson wrote: > + Arnd > > [...] > > >> >> Solution > >> >> > >> >> This is very similar to the MMC pwrseq behavior so the idea is to: > >> >> 1. Move MMC pwrseq drivers to generic place, > >> > > >> > You can do that, but I'm going to NAK

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

Hi Linus, Here are the outstanding target pending updates for v4.7-rc1. Please go ahead and pull from: git://git.kernel.org/pub/scm/linux/kernel/git/nab/target-pending.git for-next The highlights this round include: - Allow external PR/ALUA metadata path be defined at runtime via top

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

Hi Linus, Here are the outstanding target pending updates for v4.7-rc1. Please go ahead and pull from: git://git.kernel.org/pub/scm/linux/kernel/git/nab/target-pending.git for-next The highlights this round include: - Allow external PR/ALUA metadata path be defined at runtime via top

Re: [PATCH v4] platform/chrome: Add Chrome OS keyboard backlight LEDs support

On Fri, May 27, 2016 at 5:34 PM, Dmitry Torokhov wrote: > On Wed, May 11, 2016 at 11:06 AM, Olof Johansson wrote: >> On Wed, Mar 09, 2016 at 04:25:21PM -0800, Dmitry Torokhov wrote: >>> From: Simon Que >>> >>> This is a driver for

Re: [PATCH v4] platform/chrome: Add Chrome OS keyboard backlight LEDs support

On Fri, May 27, 2016 at 5:34 PM, Dmitry Torokhov wrote: > On Wed, May 11, 2016 at 11:06 AM, Olof Johansson wrote: >> On Wed, Mar 09, 2016 at 04:25:21PM -0800, Dmitry Torokhov wrote: >>> From: Simon Que >>> >>> This is a driver for ACPI-based keyboard backlight LEDs found on >>> Chromebooks. The

Re: [PATCH] Revert "platform/chrome: chromeos_laptop: Add Leon Touch"

On Thu, May 26, 2016 at 4:07 AM, Enric Balletbo i Serra wrote: > Hi Benson, Olof > > On 26/05/16 03:59, Benson Leung wrote: >> This reverts commit bff3c624dc7261a084a4d25a0b09c3fb0fec872a. >> >> Board "Leon" is otherwise known as "Toshiba CB35" and we already have >>

Re: [PATCH] Revert "platform/chrome: chromeos_laptop: Add Leon Touch"

On Thu, May 26, 2016 at 4:07 AM, Enric Balletbo i Serra wrote: > Hi Benson, Olof > > On 26/05/16 03:59, Benson Leung wrote: >> This reverts commit bff3c624dc7261a084a4d25a0b09c3fb0fec872a. >> >> Board "Leon" is otherwise known as "Toshiba CB35" and we already have >> the entry that supports that

Re: [PATCH] seccomp: plug syscall-dodging ptrace hole

On Fri, May 27, 2016 at 4:20 PM, Andy Lutomirski wrote: > On May 27, 2016 3:38 PM, "Kees Cook" wrote: >> >> On Fri, May 27, 2016 at 12:52 PM, Andy Lutomirski >> wrote: >> > On May 27, 2016 11:42 AM, "Kees Cook"

Re: [PATCH] seccomp: plug syscall-dodging ptrace hole

On Fri, May 27, 2016 at 4:20 PM, Andy Lutomirski wrote: > On May 27, 2016 3:38 PM, "Kees Cook" wrote: >> >> On Fri, May 27, 2016 at 12:52 PM, Andy Lutomirski >> wrote: >> > On May 27, 2016 11:42 AM, "Kees Cook" wrote: >> >> >> >> On Thu, May 26, 2016 at 9:45 PM, Andy Lutomirski >> >> wrote:

Re: [PATCH v2] watchdog: Add a device managed API for watchdog_register_device()

On 05/27/2016 08:33 AM, Neil Armstrong wrote: This helps in reducing code in .remove callbacks and sometimes dropping .remove callbacks entirely. Changes since v1 at http://lkml.kernel.org/r/1464251510-15554-1-git-send-email-narmstr...@baylibre.com : - Fix brackets in

Re: [PATCH v2] watchdog: Add a device managed API for watchdog_register_device()

On 05/27/2016 08:33 AM, Neil Armstrong wrote: This helps in reducing code in .remove callbacks and sometimes dropping .remove callbacks entirely. Changes since v1 at http://lkml.kernel.org/r/1464251510-15554-1-git-send-email-narmstr...@baylibre.com : - Fix brackets in

[PATCH 2/4] mfd: cros_ec: add EC_PWM function definitions

The EC_CMD_PWM_{GET,SET}_DUTY commands allow us to control a PWM that is attached to the EC, rather than the main host SoC. The API provides functionality-based (e.g., keyboard light, backlight) or index-based addressing of the PWM(s). Duty cycles are represented by a 16-bit value, where 0 maps to

[PATCH 3/4] doc: dt: pwm: add binding for ChromeOS EC PWM

The ChromeOS Embedded Controller can support controlling its attached PWMs via its host-command interface. The number of supported PWMs varies on a per-board basis, so we define a "google,max-pwms" property to handle this. And because the EC only allows specifying the duty cycle and not the

[PATCH 2/4] mfd: cros_ec: add EC_PWM function definitions

The EC_CMD_PWM_{GET,SET}_DUTY commands allow us to control a PWM that is attached to the EC, rather than the main host SoC. The API provides functionality-based (e.g., keyboard light, backlight) or index-based addressing of the PWM(s). Duty cycles are represented by a 16-bit value, where 0 maps to

[PATCH 3/4] doc: dt: pwm: add binding for ChromeOS EC PWM

The ChromeOS Embedded Controller can support controlling its attached PWMs via its host-command interface. The number of supported PWMs varies on a per-board basis, so we define a "google,max-pwms" property to handle this. And because the EC only allows specifying the duty cycle and not the

[PATCH 0/4] pwm: add support for ChromeOS EC PWM

Hi, This series adds support for the new ChromeOS EC PWM API, so we can control, e.g., the backlight when it's attached to the EC. It uses Boris's latest "atomic" hooks for the PWM API (i.e., the ->apply() callback), which were recently merged. It seems nice to have the cros_ec_cmd_xfer_status()

[PATCH 4/4] pwm: add ChromeOS EC PWM driver

Use the new ChromeOS EC EC_CMD_PWM_{GET,SET}_DUTY commands to control one or more PWMs attached to the Embedded Controller. Because the EC allows us to modify the duty cycle (as a percentage, where U16_MAX is 100%) but not the period, we assign the period a fixed value of EC_PWM_MAX_DUTY and

[PATCH 1/4] mfd: cros_ec: Add cros_ec_cmd_xfer_status helper

From: Tomeu Vizoso So that callers of cros_ec_cmd_xfer don't have to repeat boilerplate code when checking for errors from the EC side. Signed-off-by: Tomeu Vizoso Reviewed-by: Benson Leung Signed-off-by: Brian

[PATCH 0/4] pwm: add support for ChromeOS EC PWM

Hi, This series adds support for the new ChromeOS EC PWM API, so we can control, e.g., the backlight when it's attached to the EC. It uses Boris's latest "atomic" hooks for the PWM API (i.e., the ->apply() callback), which were recently merged. It seems nice to have the cros_ec_cmd_xfer_status()

[PATCH 4/4] pwm: add ChromeOS EC PWM driver

Use the new ChromeOS EC EC_CMD_PWM_{GET,SET}_DUTY commands to control one or more PWMs attached to the Embedded Controller. Because the EC allows us to modify the duty cycle (as a percentage, where U16_MAX is 100%) but not the period, we assign the period a fixed value of EC_PWM_MAX_DUTY and

[PATCH 1/4] mfd: cros_ec: Add cros_ec_cmd_xfer_status helper

From: Tomeu Vizoso So that callers of cros_ec_cmd_xfer don't have to repeat boilerplate code when checking for errors from the EC side. Signed-off-by: Tomeu Vizoso Reviewed-by: Benson Leung Signed-off-by: Brian Norris --- Stolen from: https://lkml.org/lkml/2016/4/12/342

Re: [PATCH] f2fs: fix to redirty page if fail to gc data page

Ping, On 2016/5/21 13:19, Chao Yu wrote: > From: Chao Yu > > If we fail to move data page during foreground GC, we should give another > chance to writeback that page which was set dirty previously by writer. > > Signed-off-by: Chao Yu > --- >

Re: [PATCH] f2fs: fix to redirty page if fail to gc data page

Ping, On 2016/5/21 13:19, Chao Yu wrote: > From: Chao Yu > > If we fail to move data page during foreground GC, we should give another > chance to writeback that page which was set dirty previously by writer. > > Signed-off-by: Chao Yu > --- > fs/f2fs/gc.c | 5 - > 1 file changed, 4

Re: [PATCH v4] platform/chrome: Add Chrome OS keyboard backlight LEDs support

On Wed, May 11, 2016 at 11:06 AM, Olof Johansson wrote: > On Wed, Mar 09, 2016 at 04:25:21PM -0800, Dmitry Torokhov wrote: >> From: Simon Que >> >> This is a driver for ACPI-based keyboard backlight LEDs found on >> Chromebooks. The driver locates \\_SB.KBLT

Re: [PATCH v4] platform/chrome: Add Chrome OS keyboard backlight LEDs support

On Wed, May 11, 2016 at 11:06 AM, Olof Johansson wrote: > On Wed, Mar 09, 2016 at 04:25:21PM -0800, Dmitry Torokhov wrote: >> From: Simon Que >> >> This is a driver for ACPI-based keyboard backlight LEDs found on >> Chromebooks. The driver locates \\_SB.KBLT ACPI device and exports >> backlight

Re: [GIT PULL] Please pull NFS client changes for Linux 4.7

On Fri, May 27, 2016 at 5:17 PM, Boris Ostrovsky wrote: > > It does fix it. Ok, I've committed that in my tree, will do my usual build test and push out. > This is not the first time we've hit this and people have always been > changing code to initialize fields in

Re: [GIT PULL] Please pull NFS client changes for Linux 4.7

On Fri, May 27, 2016 at 5:17 PM, Boris Ostrovsky wrote: > > It does fix it. Ok, I've committed that in my tree, will do my usual build test and push out. > This is not the first time we've hit this and people have always been > changing code to initialize fields in execution path (and I didn't

Re: [PATCH v5] KVM: halt-polling: poll for the upcoming fire timers

On Fri, 27 May 2016 11:49:26 +0200 Paolo Bonzini wrote: > > > On 26/05/2016 22:33, yunhong jiang wrote: > > On Thu, 26 May 2016 12:26:27 +0200 > > Paolo Bonzini wrote: > > > >> > >> > >> On 25/05/2016 04:47, Wanpeng Li wrote: > >>> From: Wanpeng Li

Re: [PATCH v5] KVM: halt-polling: poll for the upcoming fire timers

On Fri, 27 May 2016 11:49:26 +0200 Paolo Bonzini wrote: > > > On 26/05/2016 22:33, yunhong jiang wrote: > > On Thu, 26 May 2016 12:26:27 +0200 > > Paolo Bonzini wrote: > > > >> > >> > >> On 25/05/2016 04:47, Wanpeng Li wrote: > >>> From: Wanpeng Li > >>> > >>> If an emulated lapic timer

[git pull] Input updates for 4.7-rc0 (part 2)

Hi Linus, Please pull from: git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input.git for-linus to receive updates for the input subsystem. Just a few more driver fixes; new drivers will be coming in the next merge window. There will be a trivial conflict in

[git pull] Input updates for 4.7-rc0 (part 2)

Hi Linus, Please pull from: git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input.git for-linus to receive updates for the input subsystem. Just a few more driver fixes; new drivers will be coming in the next merge window. There will be a trivial conflict in

Re: [GIT PULL] Please pull NFS client changes for Linux 4.7

- torva...@linux-foundation.org wrote: > On Fri, May 27, 2016 at 10:14 AM, Boris Ostrovsky > wrote: > > > > This breaks on older compilers: > > > > CC fs/nfs/nfs4state.o > > /home/build/linux-linus/fs/nfs/nfs4state.c:69: error: unknown field > > ‘data’

Re: [GIT PULL] Please pull NFS client changes for Linux 4.7

- torva...@linux-foundation.org wrote: > On Fri, May 27, 2016 at 10:14 AM, Boris Ostrovsky > wrote: > > > > This breaks on older compilers: > > > > CC fs/nfs/nfs4state.o > > /home/build/linux-linus/fs/nfs/nfs4state.c:69: error: unknown field > > ‘data’ specified in initializer > >

[git pull] vfs fixes

work.lookups followups - update docs, restore killability of the places that used to take ->i_mutex killably now that we have down_write_killable() merged. Additionally, it turns out that I missed a prereq for security_d_instantiate() stuff - ->getxattr() wasn't the only thing that could

[git pull] vfs fixes

work.lookups followups - update docs, restore killability of the places that used to take ->i_mutex killably now that we have down_write_killable() merged. Additionally, it turns out that I missed a prereq for security_d_instantiate() stuff - ->getxattr() wasn't the only thing that could

Re: [PATCH v4 08/10] powerpc/powernv: Add platform support for stop instruction

On Tue, May 24, 2016 at 06:45:12PM +0530, Shreyas B. Prabhu wrote: > POWER ISA v3 defines a new idle processor core mechanism. In summary, > a) new instruction named stop is added. This instruction replaces > instructions like nap, sleep, rvwinkle. > b) new per thread SPR named Processor

Re: [PATCH v4 08/10] powerpc/powernv: Add platform support for stop instruction

On Tue, May 24, 2016 at 06:45:12PM +0530, Shreyas B. Prabhu wrote: > POWER ISA v3 defines a new idle processor core mechanism. In summary, > a) new instruction named stop is added. This instruction replaces > instructions like nap, sleep, rvwinkle. > b) new per thread SPR named Processor

Re: [GIT PULL] Please pull NFS client changes for Linux 4.7

On Fri, May 27, 2016 at 10:14 AM, Boris Ostrovsky wrote: > > This breaks on older compilers: > > CC fs/nfs/nfs4state.o > /home/build/linux-linus/fs/nfs/nfs4state.c:69: error: unknown field > ‘data’ specified in initializer Does the attached patch fix it for

Re: [GIT PULL] Please pull NFS client changes for Linux 4.7

On Fri, May 27, 2016 at 10:14 AM, Boris Ostrovsky wrote: > > This breaks on older compilers: > > CC fs/nfs/nfs4state.o > /home/build/linux-linus/fs/nfs/nfs4state.c:69: error: unknown field > ‘data’ specified in initializer Does the attached patch fix it for you? I don't have easy access

Re: [PATCH] Input: pwm-beeper - fix: scheduling while atomic

On Fri, May 27, 2016 at 11:14:27AM +0200, Manfred Schlaegl wrote: > Pwm config may sleep so defer it using a worker. > > On a Freescale i.MX53 based board we ran into "BUG: scheduling while > atomic" because input_inject_event locks interrupts, but > imx_pwm_config_v2 sleeps. > > Tested on

Re: [PATCH] Input: pwm-beeper - fix: scheduling while atomic

On Fri, May 27, 2016 at 11:14:27AM +0200, Manfred Schlaegl wrote: > Pwm config may sleep so defer it using a worker. > > On a Freescale i.MX53 based board we ran into "BUG: scheduling while > atomic" because input_inject_event locks interrupts, but > imx_pwm_config_v2 sleeps. > > Tested on

[PATCH] ARM: dts: imx: ventana: Add ext watchdog reset

bc677ff42e81bbf78308a7b66cf7b63b0f5c26b0 adds a device-tree property to specify that an external watchdog reset is used to reset other portions of the board and not just the IMX6 SoC. This adds the property to the proper watchdog as well as the pinmux for the Gateworks Ventana boards that use

[PATCH] ARM: dts: imx: ventana: Add ext watchdog reset

bc677ff42e81bbf78308a7b66cf7b63b0f5c26b0 adds a device-tree property to specify that an external watchdog reset is used to reset other portions of the board and not just the IMX6 SoC. This adds the property to the proper watchdog as well as the pinmux for the Gateworks Ventana boards that use

Re: [PATCH] remove lots of IS_ERR_VALUE abuses

On Fri, May 27, 2016 at 2:23 PM, Arnd Bergmann wrote: > > This patch changes all users of IS_ERR_VALUE() that I could find > on 32-bit ARM randconfig builds and x86 allmodconfig. For the > moment, this doesn't change the definition of IS_ERR_VALUE() > because there are probably

Re: [PATCH] remove lots of IS_ERR_VALUE abuses

On Fri, May 27, 2016 at 2:23 PM, Arnd Bergmann wrote: > > This patch changes all users of IS_ERR_VALUE() that I could find > on 32-bit ARM randconfig builds and x86 allmodconfig. For the > moment, this doesn't change the definition of IS_ERR_VALUE() > because there are probably still architecture

Re: [PATCH] seccomp: plug syscall-dodging ptrace hole

On May 27, 2016 3:38 PM, "Kees Cook" wrote: > > On Fri, May 27, 2016 at 12:52 PM, Andy Lutomirski wrote: > > On May 27, 2016 11:42 AM, "Kees Cook" wrote: > >> > >> On Thu, May 26, 2016 at 9:45 PM, Andy Lutomirski

Re: [PATCH] seccomp: plug syscall-dodging ptrace hole

On May 27, 2016 3:38 PM, "Kees Cook" wrote: > > On Fri, May 27, 2016 at 12:52 PM, Andy Lutomirski wrote: > > On May 27, 2016 11:42 AM, "Kees Cook" wrote: > >> > >> On Thu, May 26, 2016 at 9:45 PM, Andy Lutomirski > >> wrote: > >> > On Thu, May 26, 2016 at 7:41 PM, Kees Cook wrote: > >> >> On

[PATCH] tty/serial: atmel: fix RS485 half duplex with DMA

When using DMA, half duplex doesn't work properly because rx is not stopped before starting tx. Ensure we call atmel_stop_rx() in the DMA case. Signed-off-by: Alexandre Belloni --- drivers/tty/serial/atmel_serial.c | 14 -- 1 file changed, 8

[PATCH] tty/serial: atmel: fix RS485 half duplex with DMA

When using DMA, half duplex doesn't work properly because rx is not stopped before starting tx. Ensure we call atmel_stop_rx() in the DMA case. Signed-off-by: Alexandre Belloni --- drivers/tty/serial/atmel_serial.c | 14 -- 1 file changed, 8 insertions(+), 6 deletions(-) diff --git

Re: [4.1.x -- 4.6.x and probably HEAD] Reproducible unprivileged panic/TLB BUG on sparc via a stack-protected rt_sigaction() ka_restorer, courtesy of the glibc testsuite

From: Nick Alcock Date: Fri, 27 May 2016 22:44:56 +0100 > Good move. Segfaulting the process is fine! :) Any process that does > this sort of thing is clearly either terminally buggy, written by an > idiot who doesn't know what he's doing (i.e. my original patch) or >

Re: [4.1.x -- 4.6.x and probably HEAD] Reproducible unprivileged panic/TLB BUG on sparc via a stack-protected rt_sigaction() ka_restorer, courtesy of the glibc testsuite

From: Nick Alcock Date: Fri, 27 May 2016 22:44:56 +0100 > Good move. Segfaulting the process is fine! :) Any process that does > this sort of thing is clearly either terminally buggy, written by an > idiot who doesn't know what he's doing (i.e. my original patch) or > malicious. These all

Re: [BUG] Panic when systemd boot do mkdir on tmpfs mounted path with smack enabled environment

On 5/27/2016 1:24 PM, Al Viro wrote: > On Fri, May 27, 2016 at 12:48:23PM -0700, Linus Torvalds wrote: >> On Fri, May 27, 2016 at 12:43 PM, Al Viro wrote: >>> Amended and force-pushed... >> Ok, I'll ignore that branch for now, in the hopes that there will be >> actual

Re: [BUG] Panic when systemd boot do mkdir on tmpfs mounted path with smack enabled environment

On 5/27/2016 1:24 PM, Al Viro wrote: > On Fri, May 27, 2016 at 12:48:23PM -0700, Linus Torvalds wrote: >> On Fri, May 27, 2016 at 12:43 PM, Al Viro wrote: >>> Amended and force-pushed... >> Ok, I'll ignore that branch for now, in the hopes that there will be >> actual testing success. Please send

Re: [PATCH] fpga: zynq-fpga: fix build failure

Hi Sudip, On Fri, May 27, 2016 at 3:55 AM, Sudip Mukherjee wrote: > While building m32r allmodconfig the build is failing with the error: > ERROR: "bad_dma_ops" [drivers/fpga/zynq-fpga.ko] undefined! > > Xilinx Zynq FPGA is using DMA but there was no dependency while

Re: [PATCH] fpga: zynq-fpga: fix build failure

Hi Sudip, On Fri, May 27, 2016 at 3:55 AM, Sudip Mukherjee wrote: > While building m32r allmodconfig the build is failing with the error: > ERROR: "bad_dma_ops" [drivers/fpga/zynq-fpga.ko] undefined! > > Xilinx Zynq FPGA is using DMA but there was no dependency while > building. > >

Re: [PATCH] seccomp: plug syscall-dodging ptrace hole

On Fri, May 27, 2016 at 12:52 PM, Andy Lutomirski wrote: > On May 27, 2016 11:42 AM, "Kees Cook" wrote: >> >> On Thu, May 26, 2016 at 9:45 PM, Andy Lutomirski wrote: >> > On Thu, May 26, 2016 at 7:41 PM, Kees Cook

Re: [PATCH] seccomp: plug syscall-dodging ptrace hole

On Fri, May 27, 2016 at 12:52 PM, Andy Lutomirski wrote: > On May 27, 2016 11:42 AM, "Kees Cook" wrote: >> >> On Thu, May 26, 2016 at 9:45 PM, Andy Lutomirski wrote: >> > On Thu, May 26, 2016 at 7:41 PM, Kees Cook wrote: >> >> On Thu, May 26, 2016 at 7:10 PM, Andy Lutomirski >> >> wrote: >>

[PATCH v2 2/2] iommu/vt-d: use marco for dmar_domain's second level size and shift

In the origin commit, the size of the second level is hard coded to an integer, 256. This patch defines two marco for the second level size and shift. Signed-off-by: Wei Yang --- drivers/iommu/intel-iommu.c | 12 ++-- include/linux/intel-iommu.h | 2 ++ 2

[PATCH v2 2/2] iommu/vt-d: use marco for dmar_domain's second level size and shift

In the origin commit, the size of the second level is hard coded to an integer, 256. This patch defines two marco for the second level size and shift. Signed-off-by: Wei Yang --- drivers/iommu/intel-iommu.c | 12 ++-- include/linux/intel-iommu.h | 2 ++ 2 files changed, 8

[PATCH v2 1/2] iommu/vt-d: reduce extra first level entry in iommu->domains

In commit <8bf478163e69> ("iommu/vt-d: Split up iommu->domains array"), it it splits iommu->domains in two levels. Each first level contains 256 entries of second level. In case of the ndomains is exact a multiple of 256, it would have one more extra first level entry for current implementation.

[PATCH v2 1/2] iommu/vt-d: reduce extra first level entry in iommu->domains

In commit <8bf478163e69> ("iommu/vt-d: Split up iommu->domains array"), it it splits iommu->domains in two levels. Each first level contains 256 entries of second level. In case of the ndomains is exact a multiple of 256, it would have one more extra first level entry for current implementation.

[PATCH v2 0/2] fix and cleanup for iommu/vt-d

The first patch tries to improve the calculation of the dmar_domain first level entry. The second patch defines two marco for dmar_domains second level size and shift instead of using an integer. --- v2: * use DIV_ROUND_UP instead of ALIGN for the calculation. Thanks Robin Murphy

[PATCH v2 0/2] fix and cleanup for iommu/vt-d

The first patch tries to improve the calculation of the dmar_domain first level entry. The second patch defines two marco for dmar_domains second level size and shift instead of using an integer. --- v2: * use DIV_ROUND_UP instead of ALIGN for the calculation. Thanks Robin Murphy

mmotm 2016-05-27-15-19 uploaded

The mm-of-the-moment snapshot 2016-05-27-15-19 has been uploaded to http://www.ozlabs.org/~akpm/mmotm/ mmotm-readme.txt says README for mm-of-the-moment: http://www.ozlabs.org/~akpm/mmotm/ This is a snapshot of my -mm patch queue. Uploaded at random hopefully more than once a week. You

mmotm 2016-05-27-15-19 uploaded

The mm-of-the-moment snapshot 2016-05-27-15-19 has been uploaded to http://www.ozlabs.org/~akpm/mmotm/ mmotm-readme.txt says README for mm-of-the-moment: http://www.ozlabs.org/~akpm/mmotm/ This is a snapshot of my -mm patch queue. Uploaded at random hopefully more than once a week. You

Re: [PATCH v2 0/3] ACPI / button: Clarify initial lid state

On Fri, 27 May 2016 15:15:43 +0800, Lv Zheng said: > The initial _LID returning value is not reliable after boot/resume because > the BIOS vendors may implement it by returning a cached value that is only > updated when a lid notification is received. > This causes strange things happening after

Re: [PATCH v2 0/3] ACPI / button: Clarify initial lid state

On Fri, 27 May 2016 15:15:43 +0800, Lv Zheng said: > The initial _LID returning value is not reliable after boot/resume because > the BIOS vendors may implement it by returning a cached value that is only > updated when a lid notification is received. > This causes strange things happening after

[PATCH v5 4/4] watchdog: ebc-c384_wdt: Allow build for X86_64

With the introduction of the ISA_BUS_API Kconfig option, ISA-style drivers may be built for X86_64 architectures. This patch changes the ISA Kconfig option dependency of the WinSystems EBC-C384 watchdog timer driver to ISA_BUS_API, thus allowing it to build for X86_64 as it is expected to. Cc:

[PATCH v5 2/4] gpio: Allow PC/104 devices on X86_64

With the introduction of the ISA_BUS_API Kconfig option, ISA-style drivers may be built for X86_64 architectures. This patch changes the ISA Kconfig option dependency of the PC/104 drivers to ISA_BUS_API, thus allowing them to build for X86_64 as they are expected to. Cc: Alexandre Courbot

[PATCH v5 2/4] gpio: Allow PC/104 devices on X86_64

With the introduction of the ISA_BUS_API Kconfig option, ISA-style drivers may be built for X86_64 architectures. This patch changes the ISA Kconfig option dependency of the PC/104 drivers to ISA_BUS_API, thus allowing them to build for X86_64 as they are expected to. Cc: Alexandre Courbot Cc:

[PATCH v5 4/4] watchdog: ebc-c384_wdt: Allow build for X86_64

With the introduction of the ISA_BUS_API Kconfig option, ISA-style drivers may be built for X86_64 architectures. This patch changes the ISA Kconfig option dependency of the WinSystems EBC-C384 watchdog timer driver to ISA_BUS_API, thus allowing it to build for X86_64 as it is expected to. Cc:

[PATCH v5 3/4] iio: stx104: Allow build for X86_64

With the introduction of the ISA_BUS_API Kconfig option, ISA-style drivers may be built for X86_64 architectures. This patch changes the ISA Kconfig option dependency of the Apex Embedded Systems STX104 DAC driver to ISA_BUS_API, thus allowing it to build for X86_64 as it is expected to. Cc:

[PATCH v5 3/4] iio: stx104: Allow build for X86_64

With the introduction of the ISA_BUS_API Kconfig option, ISA-style drivers may be built for X86_64 architectures. This patch changes the ISA Kconfig option dependency of the Apex Embedded Systems STX104 DAC driver to ISA_BUS_API, thus allowing it to build for X86_64 as it is expected to. Cc:

[PATCH v5 1/4] isa: Allow ISA-style drivers on modern systems

Several modern devices, such as PC/104 cards, are expected to run on modern systems via an ISA bus interface. Since ISA is a legacy interface for most modern architectures, ISA support should remain disabled in general. Support for ISA-style drivers should be enabled on a per driver basis. To

[PATCH v5 1/4] isa: Allow ISA-style drivers on modern systems

Several modern devices, such as PC/104 cards, are expected to run on modern systems via an ISA bus interface. Since ISA is a legacy interface for most modern architectures, ISA support should remain disabled in general. Support for ISA-style drivers should be enabled on a per driver basis. To

[PATCH v5 0/4] Allow ISA-style drivers on modern systems

Changes in v5: - Add explicit X86 dependency to CONFIG_STX104 and CONFIG_EBC_C384_WDT since these drivers were developed with X86 architectures in mind Changes in v4: - Remove unnecessary explicit "default n" from the X86 ISA_BUS Kconfig option since Kconfig options are disabled by

[PATCH v5 0/4] Allow ISA-style drivers on modern systems

Changes in v5: - Add explicit X86 dependency to CONFIG_STX104 and CONFIG_EBC_C384_WDT since these drivers were developed with X86 architectures in mind Changes in v4: - Remove unnecessary explicit "default n" from the X86 ISA_BUS Kconfig option since Kconfig options are disabled by

Re: [PATCH] remove lots of IS_ERR_VALUE abuses

On Fri, May 27, 2016 at 11:23:25PM +0200, Arnd Bergmann wrote: > @@ -837,7 +837,7 @@ static int load_flat_shared_library(int id, struct > lib_info *libs) > > res = prepare_binprm(); > > - if (!IS_ERR_VALUE(res)) > + if (res >= 0) if (res == 0), please -

Re: [PATCH] remove lots of IS_ERR_VALUE abuses

On Fri, May 27, 2016 at 11:23:25PM +0200, Arnd Bergmann wrote: > @@ -837,7 +837,7 @@ static int load_flat_shared_library(int id, struct > lib_info *libs) > > res = prepare_binprm(); > > - if (!IS_ERR_VALUE(res)) > + if (res >= 0) if (res == 0), please -

  1   2   3   4   5   6   7   8   9   10   >