Re: [PATCH] mac80211: aead api to reduce redundancy

Hi Johannes, Thanks for your time on reviewing this. I will make changes following your review. See details below. By the way, I'm still struggling on how to run unit tests. It might take time for me to make it run on my machine. 2017-10-02 8:04 GMT-04:00 Johannes Berg

Re: [PATCH] mac80211: aead api to reduce redundancy

Hi Johannes, Thanks for your time on reviewing this. I will make changes following your review. See details below. By the way, I'm still struggling on how to run unit tests. It might take time for me to make it run on my machine. 2017-10-02 8:04 GMT-04:00 Johannes Berg : > Please use "v2" tag or

Re: [PATCH 3/5] dmaengine: Support for querying maximum trasnfer length (of an SG element)

On Mon, Oct 02, 2017 at 02:24:12PM +0300, Peter Ujfalusi wrote: > > > > Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. > Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki > > On 2017-09-26 19:54, Vinod Koul wrote: > >>> > >>> not another callback :) > >>> > >>>

Re: [PATCH 3/5] dmaengine: Support for querying maximum trasnfer length (of an SG element)

On Mon, Oct 02, 2017 at 02:24:12PM +0300, Peter Ujfalusi wrote: > > > > Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. > Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki > > On 2017-09-26 19:54, Vinod Koul wrote: > >>> > >>> not another callback :) > >>> > >>>

Re: [for-next][PATCH 15/16] ftrace: Add freeing algorithm to free ftrace_mod_maps

Hi Steve, On Sat, Oct 7, 2017 at 6:32 AM, Steven Rostedt wrote: > On Fri, 6 Oct 2017 23:41:25 -0700 > "Joel Fernandes (Google)" wrote: > >> Hi Steve, >> >> On Fri, Oct 6, 2017 at 11:07 AM, Steven Rostedt wrote: >> > From:

Re: [for-next][PATCH 15/16] ftrace: Add freeing algorithm to free ftrace_mod_maps

Hi Steve, On Sat, Oct 7, 2017 at 6:32 AM, Steven Rostedt wrote: > On Fri, 6 Oct 2017 23:41:25 -0700 > "Joel Fernandes (Google)" wrote: > >> Hi Steve, >> >> On Fri, Oct 6, 2017 at 11:07 AM, Steven Rostedt wrote: >> > From: "Steven Rostedt (VMware)" >> > >> > The ftrace_mod_map is a descriptor

[PATCH 2/2] ata: ahci_sunxi: add support for R40 SATA controller

Allwinner R40 SoC has an AHCI SATA controller like the one in A10/A20, but with a reset control and two dedicated VDD pins for this controller (one 1.2v and one 2.5v). Add support for it. Signed-off-by: Icenowy Zheng --- drivers/ata/ahci_sunxi.c | 118

[PATCH 1/2] dt-bindings: add binding for Allwinner R40 SATA AHCI controller

The Allwinner R40 SoC contains a SATA AHCI controller like the one in A10/A20 SoCs, however a reset control and two power supplies are added to it. Add a binding document for it. As a dedicated binding document is needed now for the A10/A20/R40 AHCI controller, drop the A10 compatible line from

[PATCH 2/2] ata: ahci_sunxi: add support for R40 SATA controller

Allwinner R40 SoC has an AHCI SATA controller like the one in A10/A20, but with a reset control and two dedicated VDD pins for this controller (one 1.2v and one 2.5v). Add support for it. Signed-off-by: Icenowy Zheng --- drivers/ata/ahci_sunxi.c | 118

[PATCH 1/2] dt-bindings: add binding for Allwinner R40 SATA AHCI controller

The Allwinner R40 SoC contains a SATA AHCI controller like the one in A10/A20 SoCs, however a reset control and two power supplies are added to it. Add a binding document for it. As a dedicated binding document is needed now for the A10/A20/R40 AHCI controller, drop the A10 compatible line from

[PATCH 6/6] ARM: sun8i: v40: enable USB host ports for Banana Pi M2 Berry

Banana Pi M2 Berry has an on-board USB Hub that provides 4 USB Type-A ports, and it's connected to the USB1 port of the SoC. Enable it. Signed-off-by: Icenowy Zheng --- arch/arm/boot/dts/sun8i-v40-bananapi-m2-berry.dts | 13 + 1 file changed, 13 insertions(+) diff

[PATCH 6/6] ARM: sun8i: v40: enable USB host ports for Banana Pi M2 Berry

Banana Pi M2 Berry has an on-board USB Hub that provides 4 USB Type-A ports, and it's connected to the USB1 port of the SoC. Enable it. Signed-off-by: Icenowy Zheng --- arch/arm/boot/dts/sun8i-v40-bananapi-m2-berry.dts | 13 + 1 file changed, 13 insertions(+) diff --git

[PATCH 4/6] ARM: sun8i: v40: add 5V regulator for Banana Pi M2 Berry

On the Banana Pi M2 Berry board, the 5V power output (used by HDMI, SATA and USB) is controlled via a GPIO. Add regulator node for it. Signed-off-by: Icenowy Zheng --- arch/arm/boot/dts/sun8i-v40-bananapi-m2-berry.dts | 9 + 1 file changed, 9 insertions(+) diff --git

[PATCH 2/6] ARM: sun8i: r40: add USB host port nodes for R40

From: Icenowy Zheng Allwinner R40 SoC features a USB OTG port and two USB HOST ports. Add support for the host ports in the DTSI file. The OTG controller still cannot work with existing compatibles, and needs more investigation. So it's not added yet. Signed-off-by: Icenowy

[PATCH 3/6] ARM: sun8i: r40: add 5V regulator for Banana Pi M2 Ultra

On newer revisions of the Banana Pi M2 Ultra boards, the 5V power output (used by HDMI, SATA and USB) is controller via a GPIO. Add the regulator node for it. Older revisions just have the 5V power output always on, and the GPIO is reserved on these boards. So it won't affect the older

[PATCH 2/6] ARM: sun8i: r40: add USB host port nodes for R40

From: Icenowy Zheng Allwinner R40 SoC features a USB OTG port and two USB HOST ports. Add support for the host ports in the DTSI file. The OTG controller still cannot work with existing compatibles, and needs more investigation. So it's not added yet. Signed-off-by: Icenowy Zheng ---

[PATCH 3/6] ARM: sun8i: r40: add 5V regulator for Banana Pi M2 Ultra

On newer revisions of the Banana Pi M2 Ultra boards, the 5V power output (used by HDMI, SATA and USB) is controller via a GPIO. Add the regulator node for it. Older revisions just have the 5V power output always on, and the GPIO is reserved on these boards. So it won't affect the older

[PATCH 4/6] ARM: sun8i: v40: add 5V regulator for Banana Pi M2 Berry

On the Banana Pi M2 Berry board, the 5V power output (used by HDMI, SATA and USB) is controlled via a GPIO. Add regulator node for it. Signed-off-by: Icenowy Zheng --- arch/arm/boot/dts/sun8i-v40-bananapi-m2-berry.dts | 9 + 1 file changed, 9 insertions(+) diff --git

[PATCH 5/6] ARM: sun8i: r40: enable USB host for Banana Pi M2 Ultra

From: Icenowy Zheng Banana Pi M2 Ultra board features two USB host ports, connected to the two USB host ports on the SoC. Add support for them. Signed-off-by: Icenowy Zheng --- arch/arm/boot/dts/sun8i-r40-bananapi-m2-ultra.dts | 22 ++

[PATCH 5/6] ARM: sun8i: r40: enable USB host for Banana Pi M2 Ultra

From: Icenowy Zheng Banana Pi M2 Ultra board features two USB host ports, connected to the two USB host ports on the SoC. Add support for them. Signed-off-by: Icenowy Zheng --- arch/arm/boot/dts/sun8i-r40-bananapi-m2-ultra.dts | 22 ++ 1 file changed, 22 insertions(+)

[PATCH 0/6] Allwinner R40 USB host support

This patchset adds support for the USB host ports on Allwiner R40, and enable them on Banana Pi M2 Ultra and Berry boards. The first patch adds R40 support to the USB PHY driver. The second patch adds USB PHY and EHCI/OHCI nodes to the R40 DTSI. The thrid and fourth patch adds 5V regulator for

[PATCH 0/6] Allwinner R40 USB host support

This patchset adds support for the USB host ports on Allwiner R40, and enable them on Banana Pi M2 Ultra and Berry boards. The first patch adds R40 support to the USB PHY driver. The second patch adds USB PHY and EHCI/OHCI nodes to the R40 DTSI. The thrid and fourth patch adds 5V regulator for

[PATCH 1/6] phy: sun4i-usb: add support for R40 USB PHY

Allwinner R40 features a USB PHY like the one in A64, but with 3 PHYs. Add support for it. Signed-off-by: Icenowy Zheng --- Documentation/devicetree/bindings/phy/sun4i-usb-phy.txt | 1 + drivers/phy/allwinner/phy-sun4i-usb.c | 12 2 files

[PATCH 1/6] phy: sun4i-usb: add support for R40 USB PHY

Allwinner R40 features a USB PHY like the one in A64, but with 3 PHYs. Add support for it. Signed-off-by: Icenowy Zheng --- Documentation/devicetree/bindings/phy/sun4i-usb-phy.txt | 1 + drivers/phy/allwinner/phy-sun4i-usb.c | 12 2 files changed, 13

[PATCH] staging/rtl8188eu: Fix a possible sleep-in-atomic bug in rtw_disassoc_cmd

The driver may sleep under a spinlock, and the function call path is: rtw_set_802_11_bssid(acquire the spinlock) rtw_disassoc_cmd kzalloc(GFP_KERNEL) --> may sleep To fix it, GFP_KERNEL is replaced with GFP_ATOMIC. This bug is found by my static analysis tool and my code review.

[PATCH] staging/rtl8188eu: Fix a possible sleep-in-atomic bug in rtw_disassoc_cmd

The driver may sleep under a spinlock, and the function call path is: rtw_set_802_11_bssid(acquire the spinlock) rtw_disassoc_cmd kzalloc(GFP_KERNEL) --> may sleep To fix it, GFP_KERNEL is replaced with GFP_ATOMIC. This bug is found by my static analysis tool and my code review.

[PATCH] arch/x86: remove redundant null checks before kmem_cache_destroy

Remove redundant null checks before calling kmem_cache_destroy. Found with make coccicheck M=arch/x86/kvm on linux-next tag next-20170929. Signed-off-by: Tim Hansen --- arch/x86/kvm/mmu.c | 6 ++ 1 file changed, 2 insertions(+), 4 deletions(-) diff --git

[PATCH] arch/x86: remove redundant null checks before kmem_cache_destroy

Remove redundant null checks before calling kmem_cache_destroy. Found with make coccicheck M=arch/x86/kvm on linux-next tag next-20170929. Signed-off-by: Tim Hansen --- arch/x86/kvm/mmu.c | 6 ++ 1 file changed, 2 insertions(+), 4 deletions(-) diff --git a/arch/x86/kvm/mmu.c

[PATCH 2/2] KVM: X86: XCR0 should be set to the fixed value on vCPU reset

From: Wanpeng Li SDM section 2.6 mentioned: After reset, all bits (except bit 0) in XCR0 are cleared to zero; XCR0[0] is set to 1. This patch sets XCRO to the 0x1 after vCPU reset. Cc: Paolo Bonzini Cc: Radim Krčmář

[PATCH 2/2] KVM: X86: XCR0 should be set to the fixed value on vCPU reset

From: Wanpeng Li SDM section 2.6 mentioned: After reset, all bits (except bit 0) in XCR0 are cleared to zero; XCR0[0] is set to 1. This patch sets XCRO to the 0x1 after vCPU reset. Cc: Paolo Bonzini Cc: Radim Krčmář Signed-off-by: Wanpeng Li --- arch/x86/kvm/x86.c | 2 ++ 1 file

[PATCH 1/2] KVM: VMX: Don't expose unrestricted_guest is enabled if ept is disabled

From: Wanpeng Li SDM mentioned: "If either the “unrestricted guest” VM-execution control or the “mode-based execute control for EPT” VM- execution control is 1, the “enable EPT” VM-execution control must also be 1." However, we can still observe

[PATCH 1/2] KVM: VMX: Don't expose unrestricted_guest is enabled if ept is disabled

From: Wanpeng Li SDM mentioned: "If either the “unrestricted guest” VM-execution control or the “mode-based execute control for EPT” VM- execution control is 1, the “enable EPT” VM-execution control must also be 1." However, we can still observe unrestricted_guest is Y after inserting

Re: [RESEND PATCH] gpio: omap: Fix lost edge interrupts

On 10/7/17 4:18 AM, Linus Walleij wrote: On Tue, Oct 3, 2017 at 6:17 PM, Grygorii Strashko wrote: Now acking of edge irqs happens the following way: - omap_gpio_irq_handler - "isr" = read irq status - omap_clear_gpio_irqbank(bank, isr_saved & ~level_mask);

Re: [RESEND PATCH] gpio: omap: Fix lost edge interrupts

On 10/7/17 4:18 AM, Linus Walleij wrote: On Tue, Oct 3, 2017 at 6:17 PM, Grygorii Strashko wrote: Now acking of edge irqs happens the following way: - omap_gpio_irq_handler - "isr" = read irq status - omap_clear_gpio_irqbank(bank, isr_saved & ~level_mask); ^ clear edge status,

Re: [PATCH review for 4.4 14/24] dmaengine: sun6i: allow build on ARM64 platforms (sun50i)

于 2017年10月8日 GMT+08:00 上午6:37:46, "Levin, Alexander (Sasha Levin)" 写到: >From: Icenowy Zheng > >[ Upstream commit c429ceb1e18252122ba96b52e689dcf87103c186 ] > >As 64-bit Allwinner H5 SoC has the same DMA engine with H3, the DMA >driver should be

Re: [PATCH review for 4.4 14/24] dmaengine: sun6i: allow build on ARM64 platforms (sun50i)

于 2017年10月8日 GMT+08:00 上午6:37:46, "Levin, Alexander (Sasha Levin)" 写到: >From: Icenowy Zheng > >[ Upstream commit c429ceb1e18252122ba96b52e689dcf87103c186 ] > >As 64-bit Allwinner H5 SoC has the same DMA engine with H3, the DMA >driver should be allowed to be built for ARM64, in order to make

Re: [BUG] fs/super: a possible sleep-in-atomic bug in put_super

On Sun, Oct 08, 2017 at 01:56:08AM +0100, Al Viro wrote: > What's more, we need to be careful about resize vs. drain. Right now it's > on list_lrus_mutex, but if we drop that around actual resize of an individual > list_lru, we'll need something else. Would there be any problem if we > took

Re: [BUG] fs/super: a possible sleep-in-atomic bug in put_super

On Sun, Oct 08, 2017 at 01:56:08AM +0100, Al Viro wrote: > What's more, we need to be careful about resize vs. drain. Right now it's > on list_lrus_mutex, but if we drop that around actual resize of an individual > list_lru, we'll need something else. Would there be any problem if we > took

Re: [PATCH] fs/afs/flock and fs/locks: Fix possible sleep-in-atomic bugs in posix_lock_file

On Sat, Oct 07, 2017 at 06:36:57AM -0400, Jeff Layton wrote: > On Sat, 2017-10-07 at 17:55 +0800, Jia-Ju Bai wrote: > > The kernel may sleep under a spinlock, and the function call paths are: > > afs_do_unlk (acquire the spinlock) > > posix_lock_file > > posix_lock_inode (fs/locks.c) > >

Re: [PATCH] fs/afs/flock and fs/locks: Fix possible sleep-in-atomic bugs in posix_lock_file

On Sat, Oct 07, 2017 at 06:36:57AM -0400, Jeff Layton wrote: > On Sat, 2017-10-07 at 17:55 +0800, Jia-Ju Bai wrote: > > The kernel may sleep under a spinlock, and the function call paths are: > > afs_do_unlk (acquire the spinlock) > > posix_lock_file > > posix_lock_inode (fs/locks.c) > >

Re: [PATCH v2 3/5] kernel/locking: Use atomic_cond_read_acquire when spinning in qrwlock

On Fri, Oct 06, 2017 at 01:34:40PM +, Will Deacon wrote: > The qrwlock slowpaths involve spinning when either a prospective reader > is waiting for a concurrent writer to drain, or a prospective writer is > waiting for concurrent readers to drain. In both of these situations, >

Re: [PATCH v2 3/5] kernel/locking: Use atomic_cond_read_acquire when spinning in qrwlock

On Fri, Oct 06, 2017 at 01:34:40PM +, Will Deacon wrote: > The qrwlock slowpaths involve spinning when either a prospective reader > is waiting for a concurrent writer to drain, or a prospective writer is > waiting for concurrent readers to drain. In both of these situations, >

Re: [BUG] fs/super: a possible sleep-in-atomic bug in put_super

On Sat, Oct 07, 2017 at 10:14:44PM +0100, Al Viro wrote: > 1) coallocate struct list_lru and array of struct list_lru_node > hanging off it. Turn all existing variables and struct members of that > type into pointers. init would allocate and return a pointer, destroy > would free (and

Re: [BUG] fs/super: a possible sleep-in-atomic bug in put_super

On Sat, Oct 07, 2017 at 10:14:44PM +0100, Al Viro wrote: > 1) coallocate struct list_lru and array of struct list_lru_node > hanging off it. Turn all existing variables and struct members of that > type into pointers. init would allocate and return a pointer, destroy > would free (and

Re: [PATCH] pinctrl: cherryview: fix issues caused by dynamic gpio irqs mapping

On Tue, Oct 3, 2017 at 7:00 PM, Grygorii Strashko wrote: > New GPIO IRQs are allocated and mapped dynamically by default when > GPIO IRQ infrastructure is used by cherryview-pinctrl driver. > This causes issues on some Intel platforms [1][2] with broken BIOS which >

Re: [PATCH] pinctrl: cherryview: fix issues caused by dynamic gpio irqs mapping

On Tue, Oct 3, 2017 at 7:00 PM, Grygorii Strashko wrote: > New GPIO IRQs are allocated and mapped dynamically by default when > GPIO IRQ infrastructure is used by cherryview-pinctrl driver. > This causes issues on some Intel platforms [1][2] with broken BIOS which > hardcodes Linux IRQ numbers

Re: [RFT PATCH v2] gpiolib: allow gpio irqchip to map irqs dynamically

On Thu, Sep 28, 2017 at 10:33 AM, Mika Westerberg wrote: > On Fri, Jul 21, 2017 at 11:49:00AM -0500, Grygorii Strashko wrote: >> Now IRQ mappings are always created for all (allowed) GPIOs in gpiochip in >> gpiochip_irqchip_add_key() which goes against the idea of

Re: [RFT PATCH v2] gpiolib: allow gpio irqchip to map irqs dynamically

On Thu, Sep 28, 2017 at 10:33 AM, Mika Westerberg wrote: > On Fri, Jul 21, 2017 at 11:49:00AM -0500, Grygorii Strashko wrote: >> Now IRQ mappings are always created for all (allowed) GPIOs in gpiochip in >> gpiochip_irqchip_add_key() which goes against the idea of SPARSE_IRQ and, >> as result,

Re: [PATCH] MAINTAINERS: Add git repository to Renesas pinctrl driver section

On Wed, Oct 4, 2017 at 1:35 PM, Geert Uytterhoeven wrote: > Signed-off-by: Geert Uytterhoeven Patch applied with Simon's tag. Yours, Linus Walleij

Re: [PATCH] MAINTAINERS: Add git repository to Renesas pinctrl driver section

On Wed, Oct 4, 2017 at 1:35 PM, Geert Uytterhoeven wrote: > Signed-off-by: Geert Uytterhoeven Patch applied with Simon's tag. Yours, Linus Walleij

Prize

USA Internet Command Protocol 2017 has selected your e-mail ID as lucky winner of US$800,000.00 out of US$350,000.000.00 shared worldwide for 100.000 e-mail Users. Forward your lucky number USAL77720 with your profile to the mandated payment center via any of the below internet software ip

Prize

USA Internet Command Protocol 2017 has selected your e-mail ID as lucky winner of US$800,000.00 out of US$350,000.000.00 shared worldwide for 100.000 e-mail Users. Forward your lucky number USAL77720 with your profile to the mandated payment center via any of the below internet software ip

Re: [PATCH] dt-bindings: pinctrl: Move mcp23s08 from gpio

On Thu, Oct 5, 2017 at 9:50 AM, Lars Poeschel wrote: > The mcp23s08 driver was moved from gpio to pinctrl. This moves it's > devicetree binding doc as well. So driver and binding doc are in sync > again. > > Signed-off-by: Lars Poeschel Are there no

Re: [PATCH] dt-bindings: pinctrl: Move mcp23s08 from gpio

On Thu, Oct 5, 2017 at 9:50 AM, Lars Poeschel wrote: > The mcp23s08 driver was moved from gpio to pinctrl. This moves it's > devicetree binding doc as well. So driver and binding doc are in sync > again. > > Signed-off-by: Lars Poeschel Are there no new references to the generic pin control

[PATCH] iio: adc: dln2-adc: fix build error

From: Randy Dunlap The dln2-adc driver uses interface(s) that are controlled by the IIO_TRIGGERED_BUFFER Kconfig symbol, so the driver needs to select that symbol to prevent the build error. drivers/iio/adc/dln2-adc.o: In function `dln2_adc_probe':

[PATCH] iio: adc: dln2-adc: fix build error

From: Randy Dunlap The dln2-adc driver uses interface(s) that are controlled by the IIO_TRIGGERED_BUFFER Kconfig symbol, so the driver needs to select that symbol to prevent the build error. drivers/iio/adc/dln2-adc.o: In function `dln2_adc_probe': dln2-adc.c:(.text+0x528): undefined reference

[PATCH 2/3] sched/fair: Introduce scaled capacity awareness in select_idle_sibling code path

While looking for CPUs to place running tasks on, the scheduler completely ignores the capacity stolen away by RT/IRQ tasks. This patch changes that behavior to also take the scaled capacity into account. Signed-off-by: Rohit Jain --- kernel/sched/fair.c | 37

[PATCH 2/3] sched/fair: Introduce scaled capacity awareness in select_idle_sibling code path

While looking for CPUs to place running tasks on, the scheduler completely ignores the capacity stolen away by RT/IRQ tasks. This patch changes that behavior to also take the scaled capacity into account. Signed-off-by: Rohit Jain --- kernel/sched/fair.c | 37

[PATCH 3/3] sched/fair: Introduce scaled capacity awareness in wake_affine_idle code path

wake_affine_idle returns true if the CPU can run the task. Since it is ignoring capacity, adding that check there to only return true if the CPU is full_capacity. Signed-off-by: Rohit Jain --- kernel/sched/fair.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)

[PATCH 3/3] sched/fair: Introduce scaled capacity awareness in wake_affine_idle code path

wake_affine_idle returns true if the CPU can run the task. Since it is ignoring capacity, adding that check there to only return true if the CPU is full_capacity. Signed-off-by: Rohit Jain --- kernel/sched/fair.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git

[PATCH 1/3] sched/fair: Introduce scaled capacity awareness in find_idlest_cpu code path

While looking for idle CPUs for a waking task, we should also account for the delays caused due to the bandwidth reduction by RT/IRQ tasks. This patch does that by trying to find a higher capacity CPU with minimum wake up latency. Signed-off-by: Rohit Jain ---

[PATCH 1/3] sched/fair: Introduce scaled capacity awareness in find_idlest_cpu code path

While looking for idle CPUs for a waking task, we should also account for the delays caused due to the bandwidth reduction by RT/IRQ tasks. This patch does that by trying to find a higher capacity CPU with minimum wake up latency. Signed-off-by: Rohit Jain --- kernel/sched/fair.c | 27

[PATCH v5 0/3] sched/fair: Introduce scaled capacity awareness in enqueue

Changelog: --- v1->v2: * Changed the dynamic threshold calculation as the having global state can be avoided. v2->v3: * Split up the patch for find_idlest_cpu and select_idle_sibling code paths. v3->v4: * Rebased it to

[PATCH v5 0/3] sched/fair: Introduce scaled capacity awareness in enqueue

Changelog: --- v1->v2: * Changed the dynamic threshold calculation as the having global state can be avoided. v2->v3: * Split up the patch for find_idlest_cpu and select_idle_sibling code paths. v3->v4: * Rebased it to

[PATCH review for 4.9 33/50] platform/x86: intel_mid_thermal: Fix module autoload

From: Javier Martinez Canillas [ Upstream commit a93151a72061e944a4915458b1b1d6d505c03bbf ] If the driver is built as a module, autoload won't work because the module alias information is not filled. So user-space can't match the registered device with the corresponding

[PATCH review for 4.9 33/50] platform/x86: intel_mid_thermal: Fix module autoload

From: Javier Martinez Canillas [ Upstream commit a93151a72061e944a4915458b1b1d6d505c03bbf ] If the driver is built as a module, autoload won't work because the module alias information is not filled. So user-space can't match the registered device with the corresponding module. Export the

[PATCH review for 4.9 43/50] mei: return error on notification request to a disconnected client

From: Alexander Usyskin [ Upstream commit 7c47d2ca0feca767479329da23523ed798acb854 ] Request for a notification from a disconnected client will be ignored silently by the FW but the caller should know that the operation hasn't succeeded. Signed-off-by: Alexander

[PATCH review for 4.9 38/50] brcmfmac: check brcmf_bus_get_memdump result for error

From: Rafał Miłecki [ Upstream commit f4737a62033d7f3e0db740c449fc62119da7ab8a ] This method may be unsupported (see: USB bus) or may just fail (see: SDIO bus). While at it rework logic in brcmf_sdio_bus_get_memdump function to avoid too many conditional code nesting levels.

[PATCH review for 4.9 43/50] mei: return error on notification request to a disconnected client

From: Alexander Usyskin [ Upstream commit 7c47d2ca0feca767479329da23523ed798acb854 ] Request for a notification from a disconnected client will be ignored silently by the FW but the caller should know that the operation hasn't succeeded. Signed-off-by: Alexander Usyskin Signed-off-by: Tomas

[PATCH review for 4.9 38/50] brcmfmac: check brcmf_bus_get_memdump result for error

From: Rafał Miłecki [ Upstream commit f4737a62033d7f3e0db740c449fc62119da7ab8a ] This method may be unsupported (see: USB bus) or may just fail (see: SDIO bus). While at it rework logic in brcmf_sdio_bus_get_memdump function to avoid too many conditional code nesting levels. Signed-off-by:

[PATCH review for 4.9 36/50] staging: lustre: ptlrpc: skip lock if export failed

From: Alexander Boyko [ Upstream commit 4c43c27ddc461d8473cedd70f2549614641dfbc7 ] This patch resolves IO vs eviction race. After eviction failed export stayed at stale list, a client had IO processing and reconnected during it. A client sent brw rpc with last lock

[PATCH review for 4.9 09/50] mfd: axp20x: Fix axp288 PEK_DBR and PEK_DBF irqs being swapped

From: Hans de Goede [ Upstream commit 1af468ebe45591651ec3bafc2e9ddc6fdef70ae0 ] The R in PEK_DBR stands for rising, so it should be mapped to AXP288_IRQ_POKP where the last P stands for positive edge. Likewise PEK_DBF should be mapped to the falling edge, aka the

[PATCH review for 4.9 45/50] s390/prng: Adjust generation of entropy to produce real 256 bits.

From: Harald Freudenberger [ Upstream commit d34b1acb78af41b8b8d5c60972b6555ea19f7564 ] The generate_entropy function used a sha256 for compacting together 256 bits of entropy into 32 bytes hash. However, it is questionable if a sha256 can really be used here, as

[PATCH review for 4.9 36/50] staging: lustre: ptlrpc: skip lock if export failed

From: Alexander Boyko [ Upstream commit 4c43c27ddc461d8473cedd70f2549614641dfbc7 ] This patch resolves IO vs eviction race. After eviction failed export stayed at stale list, a client had IO processing and reconnected during it. A client sent brw rpc with last lock cookie and new connection.

[PATCH review for 4.9 09/50] mfd: axp20x: Fix axp288 PEK_DBR and PEK_DBF irqs being swapped

From: Hans de Goede [ Upstream commit 1af468ebe45591651ec3bafc2e9ddc6fdef70ae0 ] The R in PEK_DBR stands for rising, so it should be mapped to AXP288_IRQ_POKP where the last P stands for positive edge. Likewise PEK_DBF should be mapped to the falling edge, aka the _N_egative edge, so it should

[PATCH review for 4.9 45/50] s390/prng: Adjust generation of entropy to produce real 256 bits.

From: Harald Freudenberger [ Upstream commit d34b1acb78af41b8b8d5c60972b6555ea19f7564 ] The generate_entropy function used a sha256 for compacting together 256 bits of entropy into 32 bytes hash. However, it is questionable if a sha256 can really be used here, as potential collisions may reduce

[PATCH review for 4.9 02/50] crypto: ccp - Set the AES size field for all modes

From: Gary R Hook [ Upstream commit f7cc02b3c3a33a10dd5bb9e5dfd22e47e09503a2 ] Ensure that the size field is correctly populated for all AES modes. Signed-off-by: Gary R Hook Signed-off-by: Herbert Xu Signed-off-by: Sasha

[PATCH review for 4.9 02/50] crypto: ccp - Set the AES size field for all modes

From: Gary R Hook [ Upstream commit f7cc02b3c3a33a10dd5bb9e5dfd22e47e09503a2 ] Ensure that the size field is correctly populated for all AES modes. Signed-off-by: Gary R Hook Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin --- drivers/crypto/ccp/ccp-dev-v5.c | 3 +--

[PATCH review for 4.9 42/50] [media] exynos4-is: fimc-is: Unmap region obtained by of_iomap()

From: Arvind Yadav [ Upstream commit 4742575cde1f3cee0ea6b41af42781672315b04b ] Free memory mapping, if fimc_is_probe is not successful. Signed-off-by: Arvind Yadav Signed-off-by: Sylwester Nawrocki Signed-off-by:

[PATCH review for 4.9 42/50] [media] exynos4-is: fimc-is: Unmap region obtained by of_iomap()

From: Arvind Yadav [ Upstream commit 4742575cde1f3cee0ea6b41af42781672315b04b ] Free memory mapping, if fimc_is_probe is not successful. Signed-off-by: Arvind Yadav Signed-off-by: Sylwester Nawrocki Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin ---

[PATCH review for 4.9 41/50] ASoC: Intel: boards: remove .pm_ops in all Atom/DPCM machine drivers

From: Pierre-Louis Bossart [ Upstream commit 3639ac1cd5177685a5c8abb7230096b680e1d497 ] This patch corrects an omission in bytcr_rt5640 and bytcr_rt5651. All existing machine drivers shall not use .pm_ops to avoid a double suspend, as initially implemented

[PATCH review for 4.9 44/50] s390/dasd: check for device error pointer within state change interrupts

From: Stefan Haberland [ Upstream commit 2202134e48a3b50320aeb9e3dd1186833e9d7e66 ] Check if the device pointer is valid. Just a sanity check since we already are in the int handler of the device. Signed-off-by: Stefan Haberland Signed-off-by:

[PATCH review for 4.9 41/50] ASoC: Intel: boards: remove .pm_ops in all Atom/DPCM machine drivers

From: Pierre-Louis Bossart [ Upstream commit 3639ac1cd5177685a5c8abb7230096b680e1d497 ] This patch corrects an omission in bytcr_rt5640 and bytcr_rt5651. All existing machine drivers shall not use .pm_ops to avoid a double suspend, as initially implemented by 3f2dcbeaeb2b ("ASoC: Intel: Remove

[PATCH review for 4.9 44/50] s390/dasd: check for device error pointer within state change interrupts

From: Stefan Haberland [ Upstream commit 2202134e48a3b50320aeb9e3dd1186833e9d7e66 ] Check if the device pointer is valid. Just a sanity check since we already are in the int handler of the device. Signed-off-by: Stefan Haberland Signed-off-by: Martin Schwidefsky Signed-off-by: Sasha Levin

[PATCH review for 4.9 25/50] ath10k: fix reading sram contents for QCA4019

From: Ashok Raj Nagarajan [ Upstream commit 7f622593cc5add77a99cd39404e8a851be9de792 ] With QCA4019 platform, SRAM address can be accessed directly from host but currently, we are assuming sram addresses cannot be accessed directly and hence we convert the addresses.

[PATCH review for 4.9 25/50] ath10k: fix reading sram contents for QCA4019

From: Ashok Raj Nagarajan [ Upstream commit 7f622593cc5add77a99cd39404e8a851be9de792 ] With QCA4019 platform, SRAM address can be accessed directly from host but currently, we are assuming sram addresses cannot be accessed directly and hence we convert the addresses. While there, clean up

[PATCH review for 4.9 46/50] s390/crypto: Extend key length check for AES-XTS in fips mode.

From: Harald Freudenberger [ Upstream commit a4f2779ecf2f42b0997fedef6fd20a931c40a3e3 ] In fips mode only xts keys with 128 bit or 125 bit are allowed. This fix extends the xts_aes_set_key function to check for these valid key lengths in fips mode. Signed-off-by:

[PATCH review for 4.9 46/50] s390/crypto: Extend key length check for AES-XTS in fips mode.

From: Harald Freudenberger [ Upstream commit a4f2779ecf2f42b0997fedef6fd20a931c40a3e3 ] In fips mode only xts keys with 128 bit or 125 bit are allowed. This fix extends the xts_aes_set_key function to check for these valid key lengths in fips mode. Signed-off-by: Harald Freudenberger

[PATCH review for 4.4 10/24] drm/amdgpu: when dpm disabled, also need to stop/start vce.

From: Rex Zhu [ Upstream commit 28ed5504ab4b211a4e589e648e5ebd1e0caa7a6a ] Signed-off-by: Rex Zhu Reviewed-by: Alex Deucher Acked-by: Christian König Signed-off-by: Alex Deucher

[PATCH review for 4.4 10/24] drm/amdgpu: when dpm disabled, also need to stop/start vce.

From: Rex Zhu [ Upstream commit 28ed5504ab4b211a4e589e648e5ebd1e0caa7a6a ] Signed-off-by: Rex Zhu Reviewed-by: Alex Deucher Acked-by: Christian König Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin --- drivers/gpu/drm/amd/amdgpu/amdgpu_vce.c | 9 + 1 file changed, 9

[PATCH review for 4.4 05/24] mfd: axp20x: Fix axp288 PEK_DBR and PEK_DBF irqs being swapped

From: Hans de Goede [ Upstream commit 1af468ebe45591651ec3bafc2e9ddc6fdef70ae0 ] The R in PEK_DBR stands for rising, so it should be mapped to AXP288_IRQ_POKP where the last P stands for positive edge. Likewise PEK_DBF should be mapped to the falling edge, aka the

[PATCH review for 4.9 47/50] [media] bt8xx: fix memory leak

From: Sudip Mukherjee [ Upstream commit 6792eb0cf9310ec240b7e7c9bfa86dff4c758c68 ] If dvb_attach() fails then we were just printing an error message and exiting but the memory allocated to state was not released. Signed-off-by: Sudip Mukherjee

[PATCH review for 4.9 08/50] mfd: ab8500-sysctrl: Handle probe deferral

From: Linus Walleij [ Upstream commit 7e9c40c63933a643908d686bd89dfc2315e8c70a ] In the current boot, clients making use of the AB8500 sysctrl may be probed before the ab8500-sysctrl driver. This gives them -EINVAL, but should rather give -EPROBE_DEFER. Before this,

[PATCH review for 4.9 47/50] [media] bt8xx: fix memory leak

From: Sudip Mukherjee [ Upstream commit 6792eb0cf9310ec240b7e7c9bfa86dff4c758c68 ] If dvb_attach() fails then we were just printing an error message and exiting but the memory allocated to state was not released. Signed-off-by: Sudip Mukherjee Signed-off-by: Hans Verkuil Signed-off-by: Mauro

[PATCH review for 4.9 08/50] mfd: ab8500-sysctrl: Handle probe deferral

From: Linus Walleij [ Upstream commit 7e9c40c63933a643908d686bd89dfc2315e8c70a ] In the current boot, clients making use of the AB8500 sysctrl may be probed before the ab8500-sysctrl driver. This gives them -EINVAL, but should rather give -EPROBE_DEFER. Before this, the abx500 clock driver

[PATCH review for 4.4 05/24] mfd: axp20x: Fix axp288 PEK_DBR and PEK_DBF irqs being swapped

From: Hans de Goede [ Upstream commit 1af468ebe45591651ec3bafc2e9ddc6fdef70ae0 ] The R in PEK_DBR stands for rising, so it should be mapped to AXP288_IRQ_POKP where the last P stands for positive edge. Likewise PEK_DBF should be mapped to the falling edge, aka the _N_egative edge, so it should

[PATCH review for 4.4 02/24] mmc: s3cmci: include linux/interrupt.h for tasklet_struct

From: Arnd Bergmann [ Upstream commit e1c6ec26b853e9062f0b3daaf695c546d0702953 ] I got this new build error on today's linux-next drivers/mmc/host/s3cmci.h:69:24: error: field 'pio_tasklet' has incomplete type struct tasklet_struct pio_tasklet; drivers/mmc/host/s3cmci.c: In

[PATCH review for 4.4 02/24] mmc: s3cmci: include linux/interrupt.h for tasklet_struct

From: Arnd Bergmann [ Upstream commit e1c6ec26b853e9062f0b3daaf695c546d0702953 ] I got this new build error on today's linux-next drivers/mmc/host/s3cmci.h:69:24: error: field 'pio_tasklet' has incomplete type struct tasklet_struct pio_tasklet; drivers/mmc/host/s3cmci.c: In function

[PATCH review for 4.9 50/50] PCI: Avoid possible deadlock on pci_lock and p->pi_lock

From: Bjorn Helgaas [ Upstream commit cdcb33f9824429a926b971bf041a6cec238f91ff ] pci_lock is an IRQ-safe spinlock that protects all accesses to PCI configuration space (see PCI_OP_READ() and PCI_OP_WRITE() in pci/access.c). The pci_cfg_access_unlock() path acquires

[PATCH review for 4.9 50/50] PCI: Avoid possible deadlock on pci_lock and p->pi_lock

From: Bjorn Helgaas [ Upstream commit cdcb33f9824429a926b971bf041a6cec238f91ff ] pci_lock is an IRQ-safe spinlock that protects all accesses to PCI configuration space (see PCI_OP_READ() and PCI_OP_WRITE() in pci/access.c). The pci_cfg_access_unlock() path acquires pci_lock, then p->pi_lock

  1   2   3   4   5   6   >