Re: [PATCH] leds: Add mutex protection in brightness_show()

Hi! > Initially the claim about no need for lock in brightness_show() > was valid as the function was just returning unchanged > LED brightness. After the addition of led_update_brightness() this The claim was probably wrong from the day one, unless brightness is of type "atomic_t".

Re: [PATCH] leds: Add mutex protection in brightness_show()

Hi! > Initially the claim about no need for lock in brightness_show() > was valid as the function was just returning unchanged > LED brightness. After the addition of led_update_brightness() this The claim was probably wrong from the day one, unless brightness is of type "atomic_t".

Re: [PATCH] leds: Add mutex protection in brightness_show()

Hi! > On 04-11-16 08:52, Jacek Anaszewski wrote: > >Initially the claim about no need for lock in brightness_show() > >was valid as the function was just returning unchanged > >LED brightness. After the addition of led_update_brightness() this > >is no longer true, as the

Re: [PATCH] leds: Add mutex protection in brightness_show()

Hi! > On 04-11-16 08:52, Jacek Anaszewski wrote: > >Initially the claim about no need for lock in brightness_show() > >was valid as the function was just returning unchanged > >LED brightness. After the addition of led_update_brightness() this > >is no longer true, as the

Re: [PATCH] usbnet: prevent device rpm suspend in usbnet_probe function

Oliver Neukum writes: > On Tue, 2016-11-08 at 13:44 -0500, Alan Stern wrote: > >> These problems could very well be caused by running at SuperSpeed >> (USB-3) instead of high speed (USB-2). >> >> Is there any way to test what happens when the device is attached to >> the

Re: [PATCH] usbnet: prevent device rpm suspend in usbnet_probe function

Oliver Neukum writes: > On Tue, 2016-11-08 at 13:44 -0500, Alan Stern wrote: > >> These problems could very well be caused by running at SuperSpeed >> (USB-3) instead of high speed (USB-2). >> >> Is there any way to test what happens when the device is attached to >> the computer by a USB-2

Re: [RFC PATCH] scsi: libsas: fix WARN on device removal

On 03/11/2016 14:58, John Garry wrote: The following patch introduces an annoying WARN when a device is removed from the SAS topology: [SCSI] libsas: prevent domain rediscovery competing with ata error handling Are there any views on this patch? I would have thought that the parties who use

Re: [RFC PATCH] scsi: libsas: fix WARN on device removal

On 03/11/2016 14:58, John Garry wrote: The following patch introduces an annoying WARN when a device is removed from the SAS topology: [SCSI] libsas: prevent domain rediscovery competing with ata error handling Are there any views on this patch? I would have thought that the parties who use

Re: Including images on Sphinx documents

Em Mon, 07 Nov 2016 12:53:55 +0200 Jani Nikula escreveu: > On Mon, 07 Nov 2016, Mauro Carvalho Chehab wrote: > > Hi Jon, > > > > I'm trying to sort out the next steps to do after KS, with regards to > > images included on RST files. > > > > The

Re: Including images on Sphinx documents

Em Mon, 07 Nov 2016 12:53:55 +0200 Jani Nikula escreveu: > On Mon, 07 Nov 2016, Mauro Carvalho Chehab wrote: > > Hi Jon, > > > > I'm trying to sort out the next steps to do after KS, with regards to > > images included on RST files. > > > > The issue is that Sphinx image support highly depends

[PATCH v9 4/8] thunderbolt: Networking state machine

This patch builds the peer to peer communication path. Communication is established by a negotiation process whereby messages are sent back and forth between the peers until a connection is established. This includes the Thunderbolt Network driver communication with the second peer via Intel

[PATCH v9 1/8] thunderbolt: Macro rename

This first patch updates the NHI Thunderbolt controller registers file to reflect that it is not only for Cactus Ridge. No functional change intended. Signed-off-by: Amir Levy Signed-off-by: Andreas Noever --- drivers/thunderbolt/nhi_regs.h |

[PATCH v9 7/8] thunderbolt: Networking doc

Adding Thunderbolt(TM) networking documentation. Signed-off-by: Amir Levy --- Documentation/00-INDEX | 2 + Documentation/thunderbolt/networking.txt | 132 +++ 2 files changed, 134 insertions(+) create mode 100644

[PATCH v9 4/8] thunderbolt: Networking state machine

This patch builds the peer to peer communication path. Communication is established by a negotiation process whereby messages are sent back and forth between the peers until a connection is established. This includes the Thunderbolt Network driver communication with the second peer via Intel

[PATCH v9 1/8] thunderbolt: Macro rename

This first patch updates the NHI Thunderbolt controller registers file to reflect that it is not only for Cactus Ridge. No functional change intended. Signed-off-by: Amir Levy Signed-off-by: Andreas Noever --- drivers/thunderbolt/nhi_regs.h | 6 +++--- 1 file changed, 3 insertions(+), 3

[PATCH v9 7/8] thunderbolt: Networking doc

Adding Thunderbolt(TM) networking documentation. Signed-off-by: Amir Levy --- Documentation/00-INDEX | 2 + Documentation/thunderbolt/networking.txt | 132 +++ 2 files changed, 134 insertions(+) create mode 100644

[PATCH v9 5/8] thunderbolt: Networking transmit and receive

This patch provides the handling interface for sending and receiving network packets between the hosts over the full communication route (using the communication path established in the previous patch). The Thunderbolt Network driver interfaces the Linux network stack and the hardware controller

[PATCH v9 5/8] thunderbolt: Networking transmit and receive

This patch provides the handling interface for sending and receiving network packets between the hosts over the full communication route (using the communication path established in the previous patch). The Thunderbolt Network driver interfaces the Linux network stack and the hardware controller

[PATCH v9 0/8] thunderbolt: Introducing Thunderbolt(TM) Networking

This driver enables Thunderbolt Networking on non-Apple platforms running Linux. Thunderbolt Networking provides peer-to-peer connections to transfer files between computers, perform PC migrations, and/or set up small workgroups with shared storage. This is a virtual connection that emulates an

[PATCH v9 8/8] thunderbolt: Adding maintainer entry

Add Amir Levy as maintainer for Thunderbolt(TM) ICM driver Signed-off-by: Amir Levy --- MAINTAINERS | 8 +++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/MAINTAINERS b/MAINTAINERS index 411e3b8..87763c44 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@

[PATCH v9 6/8] thunderbolt: Kconfig for Thunderbolt Networking

Update to the Kconfig Thunderbolt description to add Thunderbolt networking as an option. The menu item "Thunderbolt support" now offers: "Apple Hardware Support" (existing) and/or "Thunderbolt Networking" (new) You can choose the driver for your platform or build both drivers - each

[PATCH v9 8/8] thunderbolt: Adding maintainer entry

Add Amir Levy as maintainer for Thunderbolt(TM) ICM driver Signed-off-by: Amir Levy --- MAINTAINERS | 8 +++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/MAINTAINERS b/MAINTAINERS index 411e3b8..87763c44 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -10652,7 +10652,13 @@ F:

[PATCH v9 6/8] thunderbolt: Kconfig for Thunderbolt Networking

Update to the Kconfig Thunderbolt description to add Thunderbolt networking as an option. The menu item "Thunderbolt support" now offers: "Apple Hardware Support" (existing) and/or "Thunderbolt Networking" (new) You can choose the driver for your platform or build both drivers - each

[PATCH v9 0/8] thunderbolt: Introducing Thunderbolt(TM) Networking

This driver enables Thunderbolt Networking on non-Apple platforms running Linux. Thunderbolt Networking provides peer-to-peer connections to transfer files between computers, perform PC migrations, and/or set up small workgroups with shared storage. This is a virtual connection that emulates an

[PATCH v9 2/8] thunderbolt: Updating the register definitions

Adding more Thunderbolt(TM) register definitions and some helper macros. Signed-off-by: Amir Levy --- drivers/thunderbolt/nhi_regs.h | 109 + 1 file changed, 109 insertions(+) diff --git a/drivers/thunderbolt/nhi_regs.h

[PATCH v9 3/8] thunderbolt: Communication with the ICM (firmware)

This patch provides the communication protocol between the Intel Connection Manager(ICM) firmware that is operational in the Thunderbolt controller in non-Apple hardware. The ICM firmware-based controller is used for establishing and maintaining the Thunderbolt Networking connection - we need to

[PATCH v9 2/8] thunderbolt: Updating the register definitions

Adding more Thunderbolt(TM) register definitions and some helper macros. Signed-off-by: Amir Levy --- drivers/thunderbolt/nhi_regs.h | 109 + 1 file changed, 109 insertions(+) diff --git a/drivers/thunderbolt/nhi_regs.h b/drivers/thunderbolt/nhi_regs.h

[PATCH v9 3/8] thunderbolt: Communication with the ICM (firmware)

This patch provides the communication protocol between the Intel Connection Manager(ICM) firmware that is operational in the Thunderbolt controller in non-Apple hardware. The ICM firmware-based controller is used for establishing and maintaining the Thunderbolt Networking connection - we need to

[PATCH v2] leds: Add mutex protection in brightness_show()

Initially the claim about no need for lock in brightness_show() was valid as the function was just returning unchanged LED brightness. After the addition of led_update_brightness() this is no longer true, as the function can change the brightness if a LED class driver implements brightness_get

[PATCH v2] leds: Add mutex protection in brightness_show()

Initially the claim about no need for lock in brightness_show() was valid as the function was just returning unchanged LED brightness. After the addition of led_update_brightness() this is no longer true, as the function can change the brightness if a LED class driver implements brightness_get

Re: [PATCH v3 4/4] KVM: x86: emulate FXSAVE and FXRSTOR

2016-11-09 00:25+0100, Paolo Bonzini: > On 08/11/2016 20:54, Radim Krčmář wrote: >> Internal errors were reported on 16 bit fxsave and fxrstor with ipxe. >> Old Intels don't have unrestricted_guest, so we have to emulate them. >> >> The patch takes advantage of the hardware implementation. >> >>

RE: [PATCH V5 3/3] ARM64 LPC: LPC driver implementation on Hip06

Hi Arnd > -Original Message- > From: Arnd Bergmann [mailto:a...@arndb.de] > Sent: 08 November 2016 16:25 > To: Yuanzhichang > Cc: catalin.mari...@arm.com; will.dea...@arm.com; robh...@kernel.org; > bhelg...@google.com; mark.rutl...@arm.com; o...@lixom.net; linux-arm- >

Re: [PATCH v3 4/4] KVM: x86: emulate FXSAVE and FXRSTOR

2016-11-09 00:25+0100, Paolo Bonzini: > On 08/11/2016 20:54, Radim Krčmář wrote: >> Internal errors were reported on 16 bit fxsave and fxrstor with ipxe. >> Old Intels don't have unrestricted_guest, so we have to emulate them. >> >> The patch takes advantage of the hardware implementation. >> >>

RE: [PATCH V5 3/3] ARM64 LPC: LPC driver implementation on Hip06

Hi Arnd > -Original Message- > From: Arnd Bergmann [mailto:a...@arndb.de] > Sent: 08 November 2016 16:25 > To: Yuanzhichang > Cc: catalin.mari...@arm.com; will.dea...@arm.com; robh...@kernel.org; > bhelg...@google.com; mark.rutl...@arm.com; o...@lixom.net; linux-arm- >

Re: [PATCH] usbnet: prevent device rpm suspend in usbnet_probe function

On Tue, 2016-11-08 at 13:44 -0500, Alan Stern wrote: > These problems could very well be caused by running at SuperSpeed > (USB-3) instead of high speed (USB-2). > > Is there any way to test what happens when the device is attached to > the computer by a USB-2 cable? That would prevent it from

Re: [PATCH] usbnet: prevent device rpm suspend in usbnet_probe function

On Tue, 2016-11-08 at 13:44 -0500, Alan Stern wrote: > These problems could very well be caused by running at SuperSpeed > (USB-3) instead of high speed (USB-2). > > Is there any way to test what happens when the device is attached to > the computer by a USB-2 cable? That would prevent it from

Re: [PATCH/RFC v2] tools/leds: Add led_notify_mon program for monitoring brightness changes

On 11/09/2016 12:50 PM, Hans de Goede wrote: Reviewed-by: Hans de Goede Applied, thanks. -- Best regards, Jacek Anaszewski

Re: [Ksummit-discuss] Including images on Sphinx documents

On Wed, 09 Nov 2016, Markus Heiser wrote: > Am 09.11.2016 um 12:16 schrieb Jani Nikula : >>> So I vote for : >>> 1) copy (or symlink) all rst files to Documentation/output (or to the build dir specified via O= directive) and

Re: [RFC] mem-hotplug: shall we skip unmovable node when doing numa balance?

On Tue, Nov 08, 2016 at 12:43:17PM +0800, Xishi Qiu wrote: > On mem-hotplug system, there is a problem, please see the following case. > > memtester xxG, the memory will be alloced on a movable node. And after numa > balancing, the memory may be migrated to the other node, it may be a unmovable >

Re: [PATCH/RFC v2] tools/leds: Add led_notify_mon program for monitoring brightness changes

On 11/09/2016 12:50 PM, Hans de Goede wrote: Reviewed-by: Hans de Goede Applied, thanks. -- Best regards, Jacek Anaszewski

Re: [Ksummit-discuss] Including images on Sphinx documents

On Wed, 09 Nov 2016, Markus Heiser wrote: > Am 09.11.2016 um 12:16 schrieb Jani Nikula : >>> So I vote for : >>> 1) copy (or symlink) all rst files to Documentation/output (or to the build dir specified via O= directive) and generate the *.pdf there, and produce those converted

Re: [RFC] mem-hotplug: shall we skip unmovable node when doing numa balance?

On Tue, Nov 08, 2016 at 12:43:17PM +0800, Xishi Qiu wrote: > On mem-hotplug system, there is a problem, please see the following case. > > memtester xxG, the memory will be alloced on a movable node. And after numa > balancing, the memory may be migrated to the other node, it may be a unmovable >

Re: [PATCH v2 1/3] hwmon: (mcp3021) rework for DT support

On 10/27/2016 03:33 PM, Clemens Gruber wrote: Support setting the reference voltage from the device tree. Rework of driver structure, put chip specific data in a separate structure and assign it depending on device id from platform data or DT match. Signed-off-by: Clemens Gruber

Re: [PATCH v2 1/3] hwmon: (mcp3021) rework for DT support

On 10/27/2016 03:33 PM, Clemens Gruber wrote: Support setting the reference voltage from the device tree. Rework of driver structure, put chip specific data in a separate structure and assign it depending on device id from platform data or DT match. Signed-off-by: Clemens Gruber ---

Re: [PATCH v2] led: core: Use atomic bit-field for the blink-flags

Hi, On 08-11-16 14:58, Jacek Anaszewski wrote: From: Hans de Goede All the LED_BLINK* flags are accessed read-modify-write from e.g. led_set_brightness and led_blink_set_oneshot while both set_brightness_work and the blink_timer may be running. If these race then the

Re: [PATCH v2] leds: ledtrig-heartbeat: Make top brightness adjustable

Hi, On 09-11-16 11:43, Jacek Anaszewski wrote: LED class heartbeat trigger allowed only for blinking with max_brightness value. This patch adds more flexibility by exploiting part of LED core software blink infrastructure. Signed-off-by: Jacek Anaszewski Cc: Pavel

Re: [PATCH v2] leds: ledtrig-heartbeat: Make top brightness adjustable

Hi Pavel, On 11/09/2016 12:21 PM, Pavel Machek wrote: On Wed 2016-11-09 11:43:46, Jacek Anaszewski wrote: LED class heartbeat trigger allowed only for blinking with max_brightness value. This patch adds more flexibility by exploiting part of LED core software blink infrastructure.

Re: [PATCH v2] led: core: Use atomic bit-field for the blink-flags

Hi, On 08-11-16 14:58, Jacek Anaszewski wrote: From: Hans de Goede All the LED_BLINK* flags are accessed read-modify-write from e.g. led_set_brightness and led_blink_set_oneshot while both set_brightness_work and the blink_timer may be running. If these race then the modify step done by one

Re: [PATCH v2] leds: ledtrig-heartbeat: Make top brightness adjustable

Hi, On 09-11-16 11:43, Jacek Anaszewski wrote: LED class heartbeat trigger allowed only for blinking with max_brightness value. This patch adds more flexibility by exploiting part of LED core software blink infrastructure. Signed-off-by: Jacek Anaszewski Cc: Pavel Machek Cc: Hans de Goede

Re: [PATCH v2] leds: ledtrig-heartbeat: Make top brightness adjustable

Hi Pavel, On 11/09/2016 12:21 PM, Pavel Machek wrote: On Wed 2016-11-09 11:43:46, Jacek Anaszewski wrote: LED class heartbeat trigger allowed only for blinking with max_brightness value. This patch adds more flexibility by exploiting part of LED core software blink infrastructure.

Re: [PATCH/RFC v2] tools/leds: Add led_notify_mon program for monitoring brightness changes

Hi, On 08-11-16 12:36, Jacek Anaszewski wrote: LED subsystem supports POLLPRI on "brightness" sysfs file of LED class devices. This tool demonstrates how to use the feature. Signed-off-by: Jacek Anaszewski Cc: Hans de Goede Thank you. Patch

Re: [PATCH/RFC v2] tools/leds: Add led_notify_mon program for monitoring brightness changes

Hi, On 08-11-16 12:36, Jacek Anaszewski wrote: LED subsystem supports POLLPRI on "brightness" sysfs file of LED class devices. This tool demonstrates how to use the feature. Signed-off-by: Jacek Anaszewski Cc: Hans de Goede Thank you. Patch looks good to me: Reviewed-by: Hans de Goede

[PATCH 4.4 45/69] scsi: megaraid_sas: Fix data integrity failure for JBOD (passthrough) devices

4.4-stable review patch. If anyone has any objections, please let me know. -- From: Kashyap Desai commit 1e793f6fc0db920400574211c48f9157a37e3945 upstream. Commit 02b01e010afe ("megaraid_sas: return sync cache call with success") modified the

[PATCH 4.4 45/69] scsi: megaraid_sas: Fix data integrity failure for JBOD (passthrough) devices

4.4-stable review patch. If anyone has any objections, please let me know. -- From: Kashyap Desai commit 1e793f6fc0db920400574211c48f9157a37e3945 upstream. Commit 02b01e010afe ("megaraid_sas: return sync cache call with success") modified the driver to successfully complete

[PATCH 4.4 48/69] mmc: dw_mmc-pltfm: fix the potential NULL pointer dereference

4.4-stable review patch. If anyone has any objections, please let me know. -- From: Jaehoon Chung commit 45c7a4908a307a023e237a64a3eadcafc4836493 upstream. platform_get_resource can be returned the NULL pointer. Then regs->start should be referred to

[PATCH 4.4 50/69] drm/radeon/si_dpm: Limit clocks on HD86xx part

4.4-stable review patch. If anyone has any objections, please let me know. -- From: Tom St Denis commit fb9a5b0c1c9893db2e0d18544fd49e19d784a87d upstream. Limit clocks on a specific HD86xx part to avoid crashes (while awaiting an appropriate PP fix).

Re: [PATCH v2] led: core: Use atomic bit-field for the blink-flags

Since we've already agreed on keeping the flags in the leds.h, then I'm applying this patch to the for-next branch of linux-leds.git. Thanks, Jacek Anaszewski On 11/08/2016 02:58 PM, Jacek Anaszewski wrote: From: Hans de Goede All the LED_BLINK* flags are accessed

Re: [PATCH 1/4] x86/cpufeature: Add User-Mode Instruction Prevention definitions

On Tue, Nov 8, 2016 at 8:25 PM, Ricardo Neri wrote: > On Tue, 2016-11-08 at 07:32 -0800, Andy Lutomirski wrote: >> > diff --git a/arch/x86/include/asm/disabled-features.h >> b/arch/x86/include/asm/disabled-features.h >> > index 85599ad..4707445 100644 >> >

Re: [Ksummit-discuss] Including images on Sphinx documents

On Wed, 09 Nov 2016, Mauro Carvalho Chehab wrote: > Em Wed, 09 Nov 2016 13:16:55 +0200 > Jani Nikula escreveu: > >> >> 1) copy (or symlink) all rst files to Documentation/output (or to the >> >> build dir specified via O= directive) and

[PATCH 4.4 48/69] mmc: dw_mmc-pltfm: fix the potential NULL pointer dereference

4.4-stable review patch. If anyone has any objections, please let me know. -- From: Jaehoon Chung commit 45c7a4908a307a023e237a64a3eadcafc4836493 upstream. platform_get_resource can be returned the NULL pointer. Then regs->start should be referred to NULL Pointer.

[PATCH 4.4 50/69] drm/radeon/si_dpm: Limit clocks on HD86xx part

4.4-stable review patch. If anyone has any objections, please let me know. -- From: Tom St Denis commit fb9a5b0c1c9893db2e0d18544fd49e19d784a87d upstream. Limit clocks on a specific HD86xx part to avoid crashes (while awaiting an appropriate PP fix). Signed-off-by: Tom St

Re: [PATCH v2] led: core: Use atomic bit-field for the blink-flags

Since we've already agreed on keeping the flags in the leds.h, then I'm applying this patch to the for-next branch of linux-leds.git. Thanks, Jacek Anaszewski On 11/08/2016 02:58 PM, Jacek Anaszewski wrote: From: Hans de Goede All the LED_BLINK* flags are accessed read-modify-write from e.g.

Re: [PATCH 1/4] x86/cpufeature: Add User-Mode Instruction Prevention definitions

On Tue, Nov 8, 2016 at 8:25 PM, Ricardo Neri wrote: > On Tue, 2016-11-08 at 07:32 -0800, Andy Lutomirski wrote: >> > diff --git a/arch/x86/include/asm/disabled-features.h >> b/arch/x86/include/asm/disabled-features.h >> > index 85599ad..4707445 100644 >> > ---

Re: [Ksummit-discuss] Including images on Sphinx documents

On Wed, 09 Nov 2016, Mauro Carvalho Chehab wrote: > Em Wed, 09 Nov 2016 13:16:55 +0200 > Jani Nikula escreveu: > >> >> 1) copy (or symlink) all rst files to Documentation/output (or to the >> >> build dir specified via O= directive) and generate the *.pdf there, >> >> and produce those

Re: [Intel-gfx] [PATCH v3] drm: move allocation out of drm_get_format_name()

On Wednesday, 2016-11-09 02:13:25 +0100, Daniel Vetter wrote: > On Wed, Nov 09, 2016 at 02:09:16AM +0100, Daniel Vetter wrote: > > On Wed, Nov 09, 2016 at 12:17:52AM +, Eric Engestrom wrote: > > > The function's behaviour was changed in 90844f00049e, without changing > > > its signature,

Re: [Intel-gfx] [PATCH v3] drm: move allocation out of drm_get_format_name()

On Wednesday, 2016-11-09 02:13:25 +0100, Daniel Vetter wrote: > On Wed, Nov 09, 2016 at 02:09:16AM +0100, Daniel Vetter wrote: > > On Wed, Nov 09, 2016 at 12:17:52AM +, Eric Engestrom wrote: > > > The function's behaviour was changed in 90844f00049e, without changing > > > its signature,

[PATCH 4.4 69/69] HID: usbhid: add ATEN CS962 to list of quirky devices

4.4-stable review patch. If anyone has any objections, please let me know. -- From: Oliver Neukum commit cf0ea4da4c7df11f7a508b2f37518e0f117f3791 upstream. Like many similar devices it needs a quirk to work. Issuing the request gets the device into an

[PATCH 4.4 69/69] HID: usbhid: add ATEN CS962 to list of quirky devices

4.4-stable review patch. If anyone has any objections, please let me know. -- From: Oliver Neukum commit cf0ea4da4c7df11f7a508b2f37518e0f117f3791 upstream. Like many similar devices it needs a quirk to work. Issuing the request gets the device into an irrecoverable state.

[PATCH 4.4 58/69] mm/cma: silence warnings due to max() usage

4.4-stable review patch. If anyone has any objections, please let me know. -- From: Stephen Rothwell commit badbda53e505089062e194c614e6f23450bc98b2 upstream. pageblock_order can be (at least) an unsigned int or an unsigned long depending on the kernel

[PATCH 4.4 58/69] mm/cma: silence warnings due to max() usage

4.4-stable review patch. If anyone has any objections, please let me know. -- From: Stephen Rothwell commit badbda53e505089062e194c614e6f23450bc98b2 upstream. pageblock_order can be (at least) an unsigned int or an unsigned long depending on the kernel config and

Re: [PATCH V5 2/3] ARM64 LPC: Add missing range exception for special ISA

On Tue, Nov 08, 2016 at 11:47:08AM +0800, zhichang.yuan wrote: > This patch solves two issues: > 1) parse and get the right I/O range from DTS node whose parent does not > define the corresponding ranges property; > > There are some special ISA/LPC devices that work on a specific I/O range where

Re: [PATCH V5 2/3] ARM64 LPC: Add missing range exception for special ISA

On Tue, Nov 08, 2016 at 11:47:08AM +0800, zhichang.yuan wrote: > This patch solves two issues: > 1) parse and get the right I/O range from DTS node whose parent does not > define the corresponding ranges property; > > There are some special ISA/LPC devices that work on a specific I/O range where

[PATCH 4.4 44/69] mac80211: discard multicast and 4-addr A-MSDUs

4.4-stable review patch. If anyone has any objections, please let me know. -- From: Johannes Berg commit ea720935cf6686f72def9d322298bf7e9bd53377 upstream. In mac80211, multicast A-MSDUs are accepted in many cases that they shouldn't be accepted in:

[PATCH 4.4 44/69] mac80211: discard multicast and 4-addr A-MSDUs

4.4-stable review patch. If anyone has any objections, please let me know. -- From: Johannes Berg commit ea720935cf6686f72def9d322298bf7e9bd53377 upstream. In mac80211, multicast A-MSDUs are accepted in many cases that they shouldn't be accepted in: * drop A-MSDUs with a

[PATCH 4.4 63/69] UBI: fastmap: scrub PEB when bitflips are detected in a free PEB EC header

4.4-stable review patch. If anyone has any objections, please let me know. -- From: Boris Brezillon commit ecbfa8eabae9cd73522d1d3d15869703c263d859 upstream. scan_pool() does not mark the PEB for scrubing when bitflips are detected in the

[PATCH 4.4 56/69] powerpc/ptrace: Fix out of bounds array access warning

4.4-stable review patch. If anyone has any objections, please let me know. -- From: Khem Raj commit 1e407ee3b21f981140491d5b8a36422979ca246f upstream. gcc-6 correctly warns about a out of bounds access arch/powerpc/kernel/ptrace.c:407:24: warning: index

Re: [PATCH v10 4/7] x86/syscalls/32: Wire up arch_prctl on x86-32

On Tue, Nov 08, 2016 at 10:39:53AM -0800, Kyle Huey wrote: > Hook up arch_prctl to call do_arch_prctl on x86-32, and in 32 bit compat > mode on x86-64. This allows us to have arch_prctls that are not specific to function_name() > 64 bits. > > On UML, simply stub out this syscall. > >

[PATCH 4.4 41/69] Input: i8042 - add XMG C504 to keyboard reset table

4.4-stable review patch. If anyone has any objections, please let me know. -- From: Patrick Scheuring commit da25311c7ca8b0254a686fc0d597075b9aa3b683 upstream. The Schenker XMG C504 is a rebranded Gigabyte P35 v2 laptop. Therefore it also

[PATCH 4.4 40/69] dm mirror: fix read error on recovery after default leg failure

4.4-stable review patch. If anyone has any objections, please let me know. -- From: Heinz Mauelshagen commit dcb2ff56417362c31f6b430c3c531a84581e8721 upstream. If a default leg has failed, any read will cause a new operational default leg to be selected and

[PATCH 4.4 64/69] pwm: Unexport children before chip removal

4.4-stable review patch. If anyone has any objections, please let me know. -- From: David Hsu commit 0733424c9ba9f42242409d1ece780777272f7ea1 upstream. Exported pwm channels aren't removed before the pwmchip and are leaked. This results in invalid sysfs

[PATCH 4.4 43/69] firewire: net: fix fragmented datagram_size off-by-one

4.4-stable review patch. If anyone has any objections, please let me know. -- From: Stefan Richter commit e9300a4b7bbae83af1f7703938c94cf6dc6d308f upstream. RFC 2734 defines the datagram_size field in fragment encapsulation headers thus:

[PATCH 4.4 63/69] UBI: fastmap: scrub PEB when bitflips are detected in a free PEB EC header

4.4-stable review patch. If anyone has any objections, please let me know. -- From: Boris Brezillon commit ecbfa8eabae9cd73522d1d3d15869703c263d859 upstream. scan_pool() does not mark the PEB for scrubing when bitflips are detected in the EC header of a free PEB (VID header

[PATCH 4.4 56/69] powerpc/ptrace: Fix out of bounds array access warning

4.4-stable review patch. If anyone has any objections, please let me know. -- From: Khem Raj commit 1e407ee3b21f981140491d5b8a36422979ca246f upstream. gcc-6 correctly warns about a out of bounds access arch/powerpc/kernel/ptrace.c:407:24: warning: index 32 denotes an offset

Re: [PATCH v10 4/7] x86/syscalls/32: Wire up arch_prctl on x86-32

On Tue, Nov 08, 2016 at 10:39:53AM -0800, Kyle Huey wrote: > Hook up arch_prctl to call do_arch_prctl on x86-32, and in 32 bit compat > mode on x86-64. This allows us to have arch_prctls that are not specific to function_name() > 64 bits. > > On UML, simply stub out this syscall. > >

[PATCH 4.4 41/69] Input: i8042 - add XMG C504 to keyboard reset table

4.4-stable review patch. If anyone has any objections, please let me know. -- From: Patrick Scheuring commit da25311c7ca8b0254a686fc0d597075b9aa3b683 upstream. The Schenker XMG C504 is a rebranded Gigabyte P35 v2 laptop. Therefore it also needs a keyboard reset to detect the

[PATCH 4.4 40/69] dm mirror: fix read error on recovery after default leg failure

4.4-stable review patch. If anyone has any objections, please let me know. -- From: Heinz Mauelshagen commit dcb2ff56417362c31f6b430c3c531a84581e8721 upstream. If a default leg has failed, any read will cause a new operational default leg to be selected and the read is

[PATCH 4.4 64/69] pwm: Unexport children before chip removal

4.4-stable review patch. If anyone has any objections, please let me know. -- From: David Hsu commit 0733424c9ba9f42242409d1ece780777272f7ea1 upstream. Exported pwm channels aren't removed before the pwmchip and are leaked. This results in invalid sysfs files. This fix

[PATCH 4.4 43/69] firewire: net: fix fragmented datagram_size off-by-one

4.4-stable review patch. If anyone has any objections, please let me know. -- From: Stefan Richter commit e9300a4b7bbae83af1f7703938c94cf6dc6d308f upstream. RFC 2734 defines the datagram_size field in fragment encapsulation headers thus: datagram_size: The encoded size

Re: [PATCH net-next 1/2] bpf, mlx4: fix prog refcount in mlx4_en_try_alloc_resources error path

On 11/09/2016 11:58 AM, kbuild test robot wrote: [...] All errors (new ones prefixed by >>): drivers/net/ethernet/mellanox/mlx4/en_netdev.c: In function 'mlx4_xdp_set': drivers/net/ethernet/mellanox/mlx4/en_netdev.c:2752:4: error: implicit declaration of function 'bpf_prog_add_undo'

[PATCH 4.4 68/69] ubi: fastmap: Fix add_vol() return value test in ubi_attach_fastmap()

4.4-stable review patch. If anyone has any objections, please let me know. -- From: Boris Brezillon commit 40b6e61ac72e99672e47cdb99c8d7d226004169b upstream. Commit e96a8a3bb671 ("UBI: Fastmap: Do not add vol if it already exists")

[PATCH 4.4 59/69] drm/exynos: fix error handling in exynos_drm_subdrv_open

4.4-stable review patch. If anyone has any objections, please let me know. -- From: Arnd Bergmann commit 55c4b906aa2aec3fa66310ec03c6842e34a04b2a upstream. gcc-6 warns about a pointless loop in exynos_drm_subdrv_open: drivers/gpu/drm/exynos/exynos_drm_core.c:

[PATCH 4.4 59/69] drm/exynos: fix error handling in exynos_drm_subdrv_open

4.4-stable review patch. If anyone has any objections, please let me know. -- From: Arnd Bergmann commit 55c4b906aa2aec3fa66310ec03c6842e34a04b2a upstream. gcc-6 warns about a pointless loop in exynos_drm_subdrv_open: drivers/gpu/drm/exynos/exynos_drm_core.c: In function

Re: [PATCH net-next 1/2] bpf, mlx4: fix prog refcount in mlx4_en_try_alloc_resources error path

On 11/09/2016 11:58 AM, kbuild test robot wrote: [...] All errors (new ones prefixed by >>): drivers/net/ethernet/mellanox/mlx4/en_netdev.c: In function 'mlx4_xdp_set': drivers/net/ethernet/mellanox/mlx4/en_netdev.c:2752:4: error: implicit declaration of function 'bpf_prog_add_undo'

[PATCH 4.4 68/69] ubi: fastmap: Fix add_vol() return value test in ubi_attach_fastmap()

4.4-stable review patch. If anyone has any objections, please let me know. -- From: Boris Brezillon commit 40b6e61ac72e99672e47cdb99c8d7d226004169b upstream. Commit e96a8a3bb671 ("UBI: Fastmap: Do not add vol if it already exists") introduced a bug by changing the possible

[PATCH 4.4 61/69] smc91x: avoid self-comparison warning

4.4-stable review patch. If anyone has any objections, please let me know. -- From: Arnd Bergmann commit e3ebd894f084255fde19116955ba7054858ff5d6 upstream. The smc91x driver defines a macro that compares its argument to itself, apparently to get a true result

[PATCH 4.8 011/138] gpio: GPIO_GET_LINEHANDLE_IOCTL: Validate line offset

4.8-stable review patch. If anyone has any objections, please let me know. -- From: Lars-Peter Clausen commit e405f9fcb63602d35f7a419ededa3f952a395a72 upstream. The line offset that is used as an index into the descs array is provided by userspace and might

[PATCH 4.4 55/69] x86/xen: fix upper bound of pmd loop in xen_cleanhighmap()

4.4-stable review patch. If anyone has any objections, please let me know. -- From: Juergen Gross commit 1cf38741308c64d08553602b3374fb39224eeb5a upstream. xen_cleanhighmap() is operating on level2_kernel_pgt only. The upper bound of the loop setting

[PATCH 4.4 61/69] smc91x: avoid self-comparison warning

4.4-stable review patch. If anyone has any objections, please let me know. -- From: Arnd Bergmann commit e3ebd894f084255fde19116955ba7054858ff5d6 upstream. The smc91x driver defines a macro that compares its argument to itself, apparently to get a true result while using its

[PATCH 4.8 011/138] gpio: GPIO_GET_LINEHANDLE_IOCTL: Validate line offset

4.8-stable review patch. If anyone has any objections, please let me know. -- From: Lars-Peter Clausen commit e405f9fcb63602d35f7a419ededa3f952a395a72 upstream. The line offset that is used as an index into the descs array is provided by userspace and might go beyond the

[PATCH 4.4 55/69] x86/xen: fix upper bound of pmd loop in xen_cleanhighmap()

4.4-stable review patch. If anyone has any objections, please let me know. -- From: Juergen Gross commit 1cf38741308c64d08553602b3374fb39224eeb5a upstream. xen_cleanhighmap() is operating on level2_kernel_pgt only. The upper bound of the loop setting non-kernel-image entries

<    9   10   11   12   13   14   15   16   17   18   >