[PATCH] ASoC: davinci-mcasp: Fix an error handling path in 'davinci_mcasp_probe()'

All error handling paths in this function 'goto err' except this one. If one of the 2 previous memory allocations fails, we should go through the existing error handling path. Otherwise there is an unbalanced pm_runtime_enable()/pm_runtime_disable(). Fixes: dd55ff8346a9 ("ASoC: davinci-mcasp:

[PATCH] ASoC: davinci-mcasp: Fix an error handling path in 'davinci_mcasp_probe()'

All error handling paths in this function 'goto err' except this one. If one of the 2 previous memory allocations fails, we should go through the existing error handling path. Otherwise there is an unbalanced pm_runtime_enable()/pm_runtime_disable(). Fixes: dd55ff8346a9 ("ASoC: davinci-mcasp:

Re: [PATCH] clk: tegra: Use readl_relaxed_poll_timeout_atomic in tegra210_clock_init

On Fri, Sep 15, 2017 at 12:31:45PM +0300, Peter De Schrijver wrote: > Apart from the typo in the commit message (preemption rather than preemtion): Sent a v2 to correct it. And included your Acked-by. Thanks > > Acked-By: Peter De Schrijver > > On Thu, Sep 14, 2017

Re: [PATCH] clk: tegra: Use readl_relaxed_poll_timeout_atomic in tegra210_clock_init

On Fri, Sep 15, 2017 at 12:31:45PM +0300, Peter De Schrijver wrote: > Apart from the typo in the commit message (preemption rather than preemtion): Sent a v2 to correct it. And included your Acked-by. Thanks > > Acked-By: Peter De Schrijver > > On Thu, Sep 14, 2017 at 06:36:14PM -0700,

[PATCH 0/2] android: binder: resolve lru, dentry and task deadlock

This patch set removes the unused vma argument in update_page_range and resolves a potential deadlock between lru lock, task lock and dentry lock reported by lockdep. android: binder: Don't get mm from task android: binder: Remove unused vma argument drivers/android/binder_alloc.c | 36

[PATCH 0/2] android: binder: resolve lru, dentry and task deadlock

This patch set removes the unused vma argument in update_page_range and resolves a potential deadlock between lru lock, task lock and dentry lock reported by lockdep. android: binder: Don't get mm from task android: binder: Remove unused vma argument drivers/android/binder_alloc.c | 36

[PATCH 2/2] android: binder: Don't get mm from task

Use binder_alloc struct's mm_struct rather than getting a reference to the mm struct through get_task_mm to avoid a potential deadlock between lru lock, task lock and dentry lock, since a thread can be holding the task lock and the dentry lock while trying to acquire the lru lock. Acked-by: Arve

[PATCH 1/2] android: binder: Remove unused vma argument

The vma argument in update_page_range is no longer used after 74310e06 ("android: binder: Move buffer out of area shared with user space"), since mmap_handler no longer calls update_page_range with a vma. Acked-by: Arve Hjønnevåg Signed-off-by: Sherry Yang

[PATCH 2/2] android: binder: Don't get mm from task

Use binder_alloc struct's mm_struct rather than getting a reference to the mm struct through get_task_mm to avoid a potential deadlock between lru lock, task lock and dentry lock, since a thread can be holding the task lock and the dentry lock while trying to acquire the lru lock. Acked-by: Arve

[PATCH 1/2] android: binder: Remove unused vma argument

The vma argument in update_page_range is no longer used after 74310e06 ("android: binder: Move buffer out of area shared with user space"), since mmap_handler no longer calls update_page_range with a vma. Acked-by: Arve Hjønnevåg Signed-off-by: Sherry Yang --- drivers/android/binder_alloc.c |

Re: [GIT PULL] Firmware files removal for 4.14-rc1

On 2017.09.15 at 11:56 -0700, Greg KH wrote: > The following changes since commit 569dbb88e80deb68974ef6fdd6a13edb9d686261: > > Linux 4.13 (2017-09-03 13:56:17 -0700) > > are available in the git repository at: > > git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core.git/ >

Re: [GIT PULL] Firmware files removal for 4.14-rc1

On 2017.09.15 at 11:56 -0700, Greg KH wrote: > The following changes since commit 569dbb88e80deb68974ef6fdd6a13edb9d686261: > > Linux 4.13 (2017-09-03 13:56:17 -0700) > > are available in the git repository at: > > git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core.git/ >

Re: [PATCH] Revert "xhci: Limit USB2 port wake support for AMD Promontory hosts"

On Mon, Aug 28, 2017 at 9:56 PM, Kai-Heng Feng wrote: > On Mon, Aug 28, 2017 at 6:14 PM, Mathias Nyman > wrote: >> On 28.08.2017 12:29, Greg KH wrote: >> >> Adding more people who were involved in the original patch. >> >> Users are now

Re: [PATCH] Revert "xhci: Limit USB2 port wake support for AMD Promontory hosts"

On Mon, Aug 28, 2017 at 9:56 PM, Kai-Heng Feng wrote: > On Mon, Aug 28, 2017 at 6:14 PM, Mathias Nyman > wrote: >> On 28.08.2017 12:29, Greg KH wrote: >> >> Adding more people who were involved in the original patch. >> >> Users are now seeing the unresponsive USB2 ports with Promontory hosts.

Re: [PATCH] firmware: add firmware to new device's devres list for second time cache

On Tue, Aug 22, 2017 at 12:52 AM, Kai-Heng Feng wrote: > Currently, firmware will only be chached if assign_firmware_buf() gets > called. > > When a device loses its power or a USB device gets plugged to another > port under suspend, request_firmware() can still find

Re: [PATCH] firmware: add firmware to new device's devres list for second time cache

On Tue, Aug 22, 2017 at 12:52 AM, Kai-Heng Feng wrote: > Currently, firmware will only be chached if assign_firmware_buf() gets > called. > > When a device loses its power or a USB device gets plugged to another > port under suspend, request_firmware() can still find cached firmware, > but

Re: [PATCH] usb: dwc3: Fix the USB 3.0 hub detection bug after warm boot

Hello On Fri, Sep 15, 2017 at 09:01:13AM +, gustavo panizzo wrote: Hello On Thu, Sep 07, 2017 at 01:51:31PM +0300, Felipe Balbi wrote: Hi, gustavo panizzo writes: --- drivers/usb/dwc3/core.c | 33 + 1 file changed, 33 insertions(+)

Re: [PATCH] usb: dwc3: Fix the USB 3.0 hub detection bug after warm boot

Hello On Fri, Sep 15, 2017 at 09:01:13AM +, gustavo panizzo wrote: Hello On Thu, Sep 07, 2017 at 01:51:31PM +0300, Felipe Balbi wrote: Hi, gustavo panizzo writes: --- drivers/usb/dwc3/core.c | 33 + 1 file changed, 33 insertions(+) diff --git

Re: [PATCH] once: switch to new jump label API

On Tue, Aug 22, 2017 at 02:44:41PM -0400, Hannes Frederic Sowa wrote: > Eric Biggers writes: > > > From: Eric Biggers > > > > Switch the DO_ONCE() macro from the deprecated jump label API to the new > > one. The new one is more readable, and for

Re: [PATCH] once: switch to new jump label API

On Tue, Aug 22, 2017 at 02:44:41PM -0400, Hannes Frederic Sowa wrote: > Eric Biggers writes: > > > From: Eric Biggers > > > > Switch the DO_ONCE() macro from the deprecated jump label API to the new > > one. The new one is more readable, and for DO_ONCE() it also makes the > > generated code

[PATCH 2/5] ia64: Add .opd based function descriptor dereference

We are moving towards separate kernel and module function descriptor dereference callbacks. This patch enables it for IA64. For pointers that belong to the kernel - Added __start_opd and __end_opd pointers, to track the kernel .opd section address range; - Added

[PATCH 2/5] ia64: Add .opd based function descriptor dereference

We are moving towards separate kernel and module function descriptor dereference callbacks. This patch enables it for IA64. For pointers that belong to the kernel - Added __start_opd and __end_opd pointers, to track the kernel .opd section address range; - Added

[PATCH 5/5] symbol lookup: use new kernel and module dereference functions

Call appropriate function descriptor dereference ARCH callbacks: - dereference_kernel_function_descriptor() if the pointer is a kernel symbol; - dereference_module_function_descriptor() if the pointer is a module symbol. This patch also removes dereference_function_descriptor() from

[PATCH 5/5] symbol lookup: use new kernel and module dereference functions

Call appropriate function descriptor dereference ARCH callbacks: - dereference_kernel_function_descriptor() if the pointer is a kernel symbol; - dereference_module_function_descriptor() if the pointer is a module symbol. This patch also removes dereference_function_descriptor() from

[PATCH 3/5] powerpc64: Add .opd based function descriptor dereference

We are moving towards separate kernel and module function descriptor dereference callbacks. This patch enables it for powerpc64. For pointers that belong to the kernel - Added __start_opd and __end_opd pointers, to track the kernel .opd section address range; - Added

[PATCH 4/5] parisc64: Add .opd based function descriptor dereference

We are moving towards separate kernel and module function descriptor dereference callbacks. This patch enables it for parisc64. For pointers that belong to the kernel - Added __start_opd and __end_opd pointers, to track the kernel .opd section address range; - Added

[PATCH 3/5] powerpc64: Add .opd based function descriptor dereference

We are moving towards separate kernel and module function descriptor dereference callbacks. This patch enables it for powerpc64. For pointers that belong to the kernel - Added __start_opd and __end_opd pointers, to track the kernel .opd section address range; - Added

[PATCH 4/5] parisc64: Add .opd based function descriptor dereference

We are moving towards separate kernel and module function descriptor dereference callbacks. This patch enables it for parisc64. For pointers that belong to the kernel - Added __start_opd and __end_opd pointers, to track the kernel .opd section address range; - Added

[PATCH 1/5] sections: split dereference_function_descriptor()

There are two format specifiers to print out a pointer in symbolic format: '%pS/%ps' and '%pF/%pf'. On most architectures, the two mean exactly the same thing, but some architectures (ia64, ppc64, parisc64) use an indirect pointer for C function pointers, where the function pointer points to a

[PATCH 0/5] [RFC] printk/ia64/ppc64/parisc64: let's deprecate %pF/%pf printk specifiers

Hello RFC On some arches C function pointers are indirect and point to a function descriptor, which contains the actual pointer to the code. This mostly doesn't matter, except for cases when people want to print out function pointers in symbolic format, because the usual

[PATCH 1/5] sections: split dereference_function_descriptor()

There are two format specifiers to print out a pointer in symbolic format: '%pS/%ps' and '%pF/%pf'. On most architectures, the two mean exactly the same thing, but some architectures (ia64, ppc64, parisc64) use an indirect pointer for C function pointers, where the function pointer points to a

[PATCH 0/5] [RFC] printk/ia64/ppc64/parisc64: let's deprecate %pF/%pf printk specifiers

Hello RFC On some arches C function pointers are indirect and point to a function descriptor, which contains the actual pointer to the code. This mostly doesn't matter, except for cases when people want to print out function pointers in symbolic format, because the usual

Re: [PATCH] mbcache: initialize entry->e_referenced in mb_cache_entry_create()

On Thu, Jul 06, 2017 at 08:27:25PM +0200, Alexander Potapenko wrote: > KMSAN reported use of uninitialized |entry->e_referenced| in a condition > in mb_cache_shrink(): > This still hasn't been fixed yet. I think mbcache patches usually go in through the ext4 tree --- Ted, can you take this

Re: [PATCH] mbcache: initialize entry->e_referenced in mb_cache_entry_create()

On Thu, Jul 06, 2017 at 08:27:25PM +0200, Alexander Potapenko wrote: > KMSAN reported use of uninitialized |entry->e_referenced| in a condition > in mb_cache_shrink(): > This still hasn't been fixed yet. I think mbcache patches usually go in through the ext4 tree --- Ted, can you take this

[GIT PULL] PCI fixes for v4.14

PCI fix: - revert an attempt to fix a race while enabling upstream bridges because it broke iwlwifi firmware loading The following changes since commit 711aab1dbb324d321e3d84368a435a78908c7bce: vfs: constify path argument to kernel_read_file_from_path (2017-09-14 20:18:45 -0700) are

[GIT PULL] PCI fixes for v4.14

PCI fix: - revert an attempt to fix a race while enabling upstream bridges because it broke iwlwifi firmware loading The following changes since commit 711aab1dbb324d321e3d84368a435a78908c7bce: vfs: constify path argument to kernel_read_file_from_path (2017-09-14 20:18:45 -0700) are

[PATCH 2/2] mm/memory_hotplug: define find_{smallest|biggest}_section_pfn as unsigned long

find_{smallest|biggest}_section_pfn()s find the smallest/biggest section and return the pfn of the section. But the functions are defined as int. So the functions always return 0x - 0x. It means if memory address is over 16TB, the functions does not work correctly. To handle 64

[PATCH 2/2] mm/memory_hotplug: define find_{smallest|biggest}_section_pfn as unsigned long

find_{smallest|biggest}_section_pfn()s find the smallest/biggest section and return the pfn of the section. But the functions are defined as int. So the functions always return 0x - 0x. It means if memory address is over 16TB, the functions does not work correctly. To handle 64

[PATCH 1/2] mm/memory_hotplug: Change pfn_to_section_nr/section_nr_to_pfn macro to inline function

pfn_to_section_nr() and section_nr_to_pfn() are defined as macro. pfn_to_section_nr() has no issue even if it is defined as macro. But section_nr_to_pfn() has overflow issue if sec is defined as int. section_nr_to_pfn() just shifts sec by PFN_SECTION_SHIFT. If sec is defined as unsigned long,

[PATCH 1/2] mm/memory_hotplug: Change pfn_to_section_nr/section_nr_to_pfn macro to inline function

pfn_to_section_nr() and section_nr_to_pfn() are defined as macro. pfn_to_section_nr() has no issue even if it is defined as macro. But section_nr_to_pfn() has overflow issue if sec is defined as int. section_nr_to_pfn() just shifts sec by PFN_SECTION_SHIFT. If sec is defined as unsigned long,

Re: UBSAN: Undefined behaviour in ./arch/x86/include/asm/futex.h:53:13

On 09/06/17 10:23, Toralf Förster wrote: > I catched the following UBSAN spew at a stable Gentoo Linux server with > hardened tool chain (.config attached) : > > FWIW - The lines before the UBSAN might be completely unrelated - I'm unsure. > They do come from the build bot [1] I do run at that

Re: UBSAN: Undefined behaviour in ./arch/x86/include/asm/futex.h:53:13

On 09/06/17 10:23, Toralf Förster wrote: > I catched the following UBSAN spew at a stable Gentoo Linux server with > hardened tool chain (.config attached) : > > FWIW - The lines before the UBSAN might be completely unrelated - I'm unsure. > They do come from the build bot [1] I do run at that

RE: [PATCH 1/3] mm, sysctl: make VM stats configurable

-Original Message- From: Michal Hocko [mailto:mho...@kernel.org] Sent: Friday, September 15, 2017 7:50 PM To: Wang, Kemi Cc: Luis R . Rodriguez ; Kees Cook ; Andrew Morton ; Jonathan Corbet

RE: [PATCH 1/3] mm, sysctl: make VM stats configurable

-Original Message- From: Michal Hocko [mailto:mho...@kernel.org] Sent: Friday, September 15, 2017 7:50 PM To: Wang, Kemi Cc: Luis R . Rodriguez ; Kees Cook ; Andrew Morton ; Jonathan Corbet ; Mel Gorman ; Johannes Weiner ; Christopher Lameter ; Sebastian Andrzej Siewior ; Vlastimil

Re: [PATCH] scsi: aacraid: error: testing array offset 'bus' after use

Nikola, > Fix possible indexing array of bound for >hba_map[bus][cid], > where bus and cid boundary check happens later. Applied to 4.14/scsi-fixes. Thanks! -- Martin K. Petersen Oracle Linux Engineering

Re: [PATCH] scsi: aacraid: error: testing array offset 'bus' after use

Nikola, > Fix possible indexing array of bound for >hba_map[bus][cid], > where bus and cid boundary check happens later. Applied to 4.14/scsi-fixes. Thanks! -- Martin K. Petersen Oracle Linux Engineering

Re: [PATCH] csi: libcxgbi: remove redundant check and close on csk

Colin, > csk is always null on the error return path and so the non-null check > and call to cxgbi_sock_closed on csk is redundant and can be removed. Applied to 4.15/scsi-queue. -- Martin K. Petersen Oracle Linux Engineering

Re: [PATCH] csi: libcxgbi: remove redundant check and close on csk

Colin, > csk is always null on the error return path and so the non-null check > and call to cxgbi_sock_closed on csk is redundant and can be removed. Applied to 4.15/scsi-queue. -- Martin K. Petersen Oracle Linux Engineering

Re: [PATCH v4 00/11] Enhance libsas hotplug feature

Jason, > Yijing Wang handed over this topic to me. We are working on it the > last two months. We have tested the patchset for a long time. Here is > the new version. Applied patches 1-4 and 11 to 4.15/scsi-queue. I suggest you resubmit the rest to get them back on people's radar. -- Martin

Re: [PATCH v4 00/11] Enhance libsas hotplug feature

Jason, > Yijing Wang handed over this topic to me. We are working on it the > last two months. We have tested the patchset for a long time. Here is > the new version. Applied patches 1-4 and 11 to 4.15/scsi-queue. I suggest you resubmit the rest to get them back on people's radar. -- Martin

Re: [BACKPORT] swiotlb-xen: implement xen_swiotlb_dma_mmap callback

On Thu, Sep 14, 2017 at 04:23:05PM -0700, Stefano Stabellini wrote: > Hi all, > > We are getting reports from Xen on ARM users about DMA issues. The > problem is that the commit below > (7e91c7df29b5e196de3dc6f086c8937973bd0b88) is necessary to support mmap > on Xen on ARM. It is self-contained

Re: [BACKPORT] swiotlb-xen: implement xen_swiotlb_dma_mmap callback

On Thu, Sep 14, 2017 at 04:23:05PM -0700, Stefano Stabellini wrote: > Hi all, > > We are getting reports from Xen on ARM users about DMA issues. The > problem is that the commit below > (7e91c7df29b5e196de3dc6f086c8937973bd0b88) is necessary to support mmap > on Xen on ARM. It is self-contained

[PATCH 2/6] mm, x86 : introduce arch_pkeys_enabled()

Arch neutral code needs to know if the architecture supports protection keys to display protection key in smaps. Hence introducing arch_pkeys_enabled(). This patch also provides x86 implementation for arch_pkeys_enabled(). Signed-off-by: Ram Pai ---

[PATCH 2/6] mm, x86 : introduce arch_pkeys_enabled()

Arch neutral code needs to know if the architecture supports protection keys to display protection key in smaps. Hence introducing arch_pkeys_enabled(). This patch also provides x86 implementation for arch_pkeys_enabled(). Signed-off-by: Ram Pai --- arch/x86/include/asm/pkeys.h |1 +

[PATCH 4/6] mm/mprotect, powerpc/mm/pkeys, x86/mm/pkeys: Add sysfs interface

From: Thiago Jung Bauermann Expose useful information for programs using memory protection keys. Provide implementation for powerpc and x86. On a powerpc system with pkeys support, here is what is shown: $ head /sys/kernel/mm/protection_keys/* ==>

[PATCH 4/6] mm/mprotect, powerpc/mm/pkeys, x86/mm/pkeys: Add sysfs interface

From: Thiago Jung Bauermann Expose useful information for programs using memory protection keys. Provide implementation for powerpc and x86. On a powerpc system with pkeys support, here is what is shown: $ head /sys/kernel/mm/protection_keys/* ==>

[PATCH 3/6] mm: display pkey in smaps if arch_pkeys_enabled() is true

Currently the architecture specific code is expected to display the protection keys in smap for a given vma. This can lead to redundant code and possibly to divergent formats in which the key gets displayed. This patch changes the implementation. It displays the pkey only if the

[PATCH 3/6] mm: display pkey in smaps if arch_pkeys_enabled() is true

Currently the architecture specific code is expected to display the protection keys in smap for a given vma. This can lead to redundant code and possibly to divergent formats in which the key gets displayed. This patch changes the implementation. It displays the pkey only if the

[PATCH 1/6] mm: introduce an additional vma bit for powerpc pkey

Currently only 4bits are allocated in the vma flags to hold 16 keys. This is sufficient for x86. PowerPC supports 32 keys, which needs 5bits. This patch allocates an additional bit. Signed-off-by: Ram Pai --- fs/proc/task_mmu.c |6 -- include/linux/mm.h | 16

[PATCH 1/6] mm: introduce an additional vma bit for powerpc pkey

Currently only 4bits are allocated in the vma flags to hold 16 keys. This is sufficient for x86. PowerPC supports 32 keys, which needs 5bits. This patch allocates an additional bit. Signed-off-by: Ram Pai --- fs/proc/task_mmu.c |6 -- include/linux/mm.h | 16 ++-- 2

[PATCH 6/6] Documentation/vm: PowerPC specific updates to memory protection keys

Add documentation updates that capture PowerPC specific changes. Signed-off-by: Thiago Jung Bauermann Signed-off-by: Ram Pai --- Documentation/vm/protection-keys.txt | 125 +++--- 1 files changed, 100 insertions(+),

[PATCH 6/6] Documentation/vm: PowerPC specific updates to memory protection keys

Add documentation updates that capture PowerPC specific changes. Signed-off-by: Thiago Jung Bauermann Signed-off-by: Ram Pai --- Documentation/vm/protection-keys.txt | 125 +++--- 1 files changed, 100 insertions(+), 25 deletions(-) diff --git

[PATCH 0/6] mm, x86, powerpc: Memory Protection Keys enhancement

The patch-series enhances memory protection keys feature. The patch(1) introduces an additional vma bit to support 32 pkeys. PowerPC supports 32 pkeys. The patch(2,3) introduces a new interface arch_pkeys_enabled(), this interface can be used by arch-neutral code to display protection

[PATCH 0/6] mm, x86, powerpc: Memory Protection Keys enhancement

The patch-series enhances memory protection keys feature. The patch(1) introduces an additional vma bit to support 32 pkeys. PowerPC supports 32 pkeys. The patch(2,3) introduces a new interface arch_pkeys_enabled(), this interface can be used by arch-neutral code to display protection

[PATCH 5/6] Documentation/x86: Move protecton key documentation to arch neutral directory

Since PowerPC and Intel both support memory protection keys, moving the documenation to arch-neutral directory. Signed-off-by: Ram Pai --- Documentation/vm/protection-keys.txt | 85 + Documentation/x86/protection-keys.txt | 85

[PATCH 5/6] Documentation/x86: Move protecton key documentation to arch neutral directory

Since PowerPC and Intel both support memory protection keys, moving the documenation to arch-neutral directory. Signed-off-by: Ram Pai --- Documentation/vm/protection-keys.txt | 85 + Documentation/x86/protection-keys.txt | 85

Re: [PATCH v2] HID: asus: Add support for Fn keys on Asus ROG G752

On Thu, 7 Sep 2017, Maxime Bellengé wrote: > This patch adds support for Fn keys on Asus ROG G752 laptop. > The report descriptor is broken so I fixed it. > > Tested on an Asus G752VT. > Resent fix white space fixes Those whitespace fixes were almost right :) Except for the quirk/blacklist

Re: [PATCH v2] HID: asus: Add support for Fn keys on Asus ROG G752

On Thu, 7 Sep 2017, Maxime Bellengé wrote: > This patch adds support for Fn keys on Asus ROG G752 laptop. > The report descriptor is broken so I fixed it. > > Tested on an Asus G752VT. > Resent fix white space fixes Those whitespace fixes were almost right :) Except for the quirk/blacklist

Re: [PATCH] Asoc: rockchip: Init dapm routes dynamically

El Tue, Sep 05, 2017 at 12:14:01PM +0800 Jeffy Chen ha dit: > Currently we are using a fixed list of dapm routes. > > Init dapm routes dynamically when parsing dailinks, since we are > supporting optional codecs. > > Signed-off-by: Jeffy Chen > --- > >

Re: [PATCH] Asoc: rockchip: Init dapm routes dynamically

El Tue, Sep 05, 2017 at 12:14:01PM +0800 Jeffy Chen ha dit: > Currently we are using a fixed list of dapm routes. > > Init dapm routes dynamically when parsing dailinks, since we are > supporting optional codecs. > > Signed-off-by: Jeffy Chen > --- > > sound/soc/rockchip/rk3399_gru_sound.c |

[PATCH] staging: lustre: lnet: Replace list_for_each with list_for_each_entry

Replace use of the combination of list_for_each and list_entry with list_for_each_entry to simplify the code and remove variables that are used only in list_for_each. Issue found and corrected using Coccinelle script: @r@ expression head, member, e; type T1, T2, T3; iterator name list_for_each,

[PATCH] staging: lustre: lnet: Replace list_for_each with list_for_each_entry

Replace use of the combination of list_for_each and list_entry with list_for_each_entry to simplify the code and remove variables that are used only in list_for_each. Issue found and corrected using Coccinelle script: @r@ expression head, member, e; type T1, T2, T3; iterator name list_for_each,

[PATCH 0/1] acpi: unbreak ACPI_HANDLE(), encapsulate fwnode_operations

From: John Hubbard Hi everyone, I really don't know for sure which fix is going to be preferred--the following patch, or just an obvious one-line fix that changes DECLARE_ACPI_FWNODE_OPS() so that it invokes EXPORT_SYMBOL, instead of EXPORT_SYMBOL_GPL. I explained the

[PATCH 0/1] acpi: unbreak ACPI_HANDLE(), encapsulate fwnode_operations

From: John Hubbard Hi everyone, I really don't know for sure which fix is going to be preferred--the following patch, or just an obvious one-line fix that changes DECLARE_ACPI_FWNODE_OPS() so that it invokes EXPORT_SYMBOL, instead of EXPORT_SYMBOL_GPL. I explained the reasoning in PATCH 1/1,

[PATCH 1/1] acpi: unbreak ACPI_HANDLE(), encapsulate fwnode_operations

From: John Hubbard Due to commit db3e50f3234b ("device property: Get rid of struct fwnode_handle type field"), ACPI_HANDLE() inadvertently became a GPL-only call. The call path that led to that was: ACPI_HANDLE() ACPI_COMPANION() to_acpi_device_node()

[PATCH 1/1] acpi: unbreak ACPI_HANDLE(), encapsulate fwnode_operations

From: John Hubbard Due to commit db3e50f3234b ("device property: Get rid of struct fwnode_handle type field"), ACPI_HANDLE() inadvertently became a GPL-only call. The call path that led to that was: ACPI_HANDLE() ACPI_COMPANION() to_acpi_device_node()

Re: [PATCH 5/7] Support new Alps device that name is T4

On Tue, 12 Sep 2017, Masaki Ota wrote: > From: Masaki Ota > -Add T4 device code and Product ID > -This device is used on HP EliteBook 1000 series and Zbook Stduio [ ... snip ... ] > Signed-off-by: Masaki Ota > +static int

Re: [PATCH 5/7] Support new Alps device that name is T4

On Tue, 12 Sep 2017, Masaki Ota wrote: > From: Masaki Ota > -Add T4 device code and Product ID > -This device is used on HP EliteBook 1000 series and Zbook Stduio [ ... snip ... ] > Signed-off-by: Masaki Ota > +static int t4_read_write_register(struct hid_device *hdev, u32 address, > + u8

Re: [PATCH] Support new Alps HID Touchpad device

On Tue, 12 Sep 2017, Masaki Ota wrote: > This is the patch for support new Alps HID Touchpad device. > I submitted these patch before, but it was not completed. > So I separate the patch to some parts and release it again. Hi, I have a few minor comments -- as in the past, I'd like to ask for

Re: [PATCH] Support new Alps HID Touchpad device

On Tue, 12 Sep 2017, Masaki Ota wrote: > This is the patch for support new Alps HID Touchpad device. > I submitted these patch before, but it was not completed. > So I separate the patch to some parts and release it again. Hi, I have a few minor comments -- as in the past, I'd like to ask for

Re: [PATCH v2 2/3] livepatch: add atomic replace

On Fri, Sep 15, 2017 at 05:46:58PM +0200, Petr Mladek wrote: > On Thu 2017-09-14 08:31:24, Jason Baron wrote: > > > > > > On 09/14/2017 06:32 AM, Petr Mladek wrote: > > > On Tue 2017-09-12 23:47:32, Jason Baron wrote: > > >> > > >> > > >> On 09/12/2017 01:35 AM, Petr Mladek wrote: > > >>> On Mon

Re: [PATCH v2 2/3] livepatch: add atomic replace

On Fri, Sep 15, 2017 at 05:46:58PM +0200, Petr Mladek wrote: > On Thu 2017-09-14 08:31:24, Jason Baron wrote: > > > > > > On 09/14/2017 06:32 AM, Petr Mladek wrote: > > > On Tue 2017-09-12 23:47:32, Jason Baron wrote: > > >> > > >> > > >> On 09/12/2017 01:35 AM, Petr Mladek wrote: > > >>> On Mon

Re: [PATCH 5/5] usb: usb251xb: Add copyrights

On Fri, Sep 15, 2017 at 04:53:13PM -0700, Greg KH wrote: > On Sat, Sep 16, 2017 at 02:45:17AM +0300, Serge Semin wrote: > > On Fri, Sep 15, 2017 at 04:40:28PM -0700, Greg KH > > wrote: > > > On Sat, Sep 16, 2017 at 02:31:13AM +0300, Serge

Re: [PATCH 5/5] usb: usb251xb: Add copyrights

On Fri, Sep 15, 2017 at 04:53:13PM -0700, Greg KH wrote: > On Sat, Sep 16, 2017 at 02:45:17AM +0300, Serge Semin wrote: > > On Fri, Sep 15, 2017 at 04:40:28PM -0700, Greg KH > > wrote: > > > On Sat, Sep 16, 2017 at 02:31:13AM +0300, Serge Semin wrote: > > > > Signed-off-by: Serge Semin > > >

Re: [PATCH 1/5] usb: usb251xb: Add USB2517/i hub support

On Fri, Sep 15, 2017 at 04:45:14PM -0700, Greg KH wrote: > On Sat, Sep 16, 2017 at 02:31:09AM +0300, Serge Semin wrote: > > USB2517i hubs are very like USB251xb devices series. They have almost > > the same configuration registers space except number of ports, led > >

Re: [PATCH 1/5] usb: usb251xb: Add USB2517/i hub support

On Fri, Sep 15, 2017 at 04:45:14PM -0700, Greg KH wrote: > On Sat, Sep 16, 2017 at 02:31:09AM +0300, Serge Semin wrote: > > USB2517i hubs are very like USB251xb devices series. They have almost > > the same configuration registers space except number of ports, led > > configurations and lack of

Re: [PATCH 5/5] usb: usb251xb: Add copyrights

On Sat, Sep 16, 2017 at 02:45:17AM +0300, Serge Semin wrote: > On Fri, Sep 15, 2017 at 04:40:28PM -0700, Greg KH > wrote: > > On Sat, Sep 16, 2017 at 02:31:13AM +0300, Serge Semin wrote: > > > Signed-off-by: Serge Semin > > > --- > > >

Re: [PATCH 5/5] usb: usb251xb: Add copyrights

On Sat, Sep 16, 2017 at 02:45:17AM +0300, Serge Semin wrote: > On Fri, Sep 15, 2017 at 04:40:28PM -0700, Greg KH > wrote: > > On Sat, Sep 16, 2017 at 02:31:13AM +0300, Serge Semin wrote: > > > Signed-off-by: Serge Semin > > > --- > > > drivers/usb/misc/usb251xb.c | 1 + > > > 1 file changed, 1

Re: [PATCH V5 0/4] Add Broadcom STB USB phy driver

On September 4, 2017 11:11:47 PM PDT, Kishon Vijay Abraham I wrote: >Florian, > >On Saturday 02 September 2017 07:46 AM, Florian Fainelli wrote: >> >> >> On 08/25/2017 10:51 AM, Al Cooper wrote: >>> Add a new USB Phy driver for Broadcom STB SoCs. This driver >>> supports

Re: [PATCH V5 0/4] Add Broadcom STB USB phy driver

On September 4, 2017 11:11:47 PM PDT, Kishon Vijay Abraham I wrote: >Florian, > >On Saturday 02 September 2017 07:46 AM, Florian Fainelli wrote: >> >> >> On 08/25/2017 10:51 AM, Al Cooper wrote: >>> Add a new USB Phy driver for Broadcom STB SoCs. This driver >>> supports Broadcom STB ARM SoCs.

[git pull] drm amd fixes for 4.14-rc1

Hi Linus, Just had a single AMD fixes pull for Alex for rc1. Dave. The following changes since commit 7846b12fe0b5feab5446d892f41b5140c1419109: Merge branch 'drm-vmwgfx-next' of git://people.freedesktop.org/~syeh/repos_linux into drm-next (2017-08-29 10:38:14 +1000) are available in the git

[git pull] drm amd fixes for 4.14-rc1

Hi Linus, Just had a single AMD fixes pull for Alex for rc1. Dave. The following changes since commit 7846b12fe0b5feab5446d892f41b5140c1419109: Merge branch 'drm-vmwgfx-next' of git://people.freedesktop.org/~syeh/repos_linux into drm-next (2017-08-29 10:38:14 +1000) are available in the git

Re: [PATCH 1/5] usb: usb251xb: Add USB2517/i hub support

On Sat, Sep 16, 2017 at 02:31:09AM +0300, Serge Semin wrote: > USB2517i hubs are very like USB251xb devices series. They have almost > the same configuration registers space except number of ports, led > configurations and lack of battery settings. All these peculiarities > are reflected in this

Re: [PATCH 5/5] usb: usb251xb: Add copyrights

On Fri, Sep 15, 2017 at 04:40:28PM -0700, Greg KH wrote: > On Sat, Sep 16, 2017 at 02:31:13AM +0300, Serge Semin wrote: > > Signed-off-by: Serge Semin > > --- > > drivers/usb/misc/usb251xb.c | 1 + > > 1 file changed, 1 insertions(+), 0

Re: [PATCH 1/5] usb: usb251xb: Add USB2517/i hub support

On Sat, Sep 16, 2017 at 02:31:09AM +0300, Serge Semin wrote: > USB2517i hubs are very like USB251xb devices series. They have almost > the same configuration registers space except number of ports, led > configurations and lack of battery settings. All these peculiarities > are reflected in this

Re: [PATCH 5/5] usb: usb251xb: Add copyrights

On Fri, Sep 15, 2017 at 04:40:28PM -0700, Greg KH wrote: > On Sat, Sep 16, 2017 at 02:31:13AM +0300, Serge Semin wrote: > > Signed-off-by: Serge Semin > > --- > > drivers/usb/misc/usb251xb.c | 1 + > > 1 file changed, 1 insertions(+), 0 deletion(-) > > I can't take patches without any

Re: [PATCH] vfs: introduce UMOUNT_WAIT which waits for umount completion

On Fri, Sep 15, 2017 at 04:29:11PM -0700, Jaegeuk Kim wrote: > The mntput() in delayed_fput() is the last function call. So before that > moment, > sys_umount() may see mnt_get_count() as 2, so it avoids EBUSY condition. I'm > not > sure why it check over 2 tho. Because it has just grabbed a

Re: [PATCH] vfs: introduce UMOUNT_WAIT which waits for umount completion

On Fri, Sep 15, 2017 at 04:29:11PM -0700, Jaegeuk Kim wrote: > The mntput() in delayed_fput() is the last function call. So before that > moment, > sys_umount() may see mnt_get_count() as 2, so it avoids EBUSY condition. I'm > not > sure why it check over 2 tho. Because it has just grabbed a

Re: [PATCH 5/5] usb: usb251xb: Add copyrights

On Fri, Sep 15, 2017 at 04:40:28PM -0700, Greg KH wrote: > On Sat, Sep 16, 2017 at 02:31:13AM +0300, Serge Semin wrote: > > Signed-off-by: Serge Semin > > --- > > drivers/usb/misc/usb251xb.c | 1 + > > 1 file changed, 1 insertions(+), 0 deletion(-) > > I can't take

Re: [PATCH 5/5] usb: usb251xb: Add copyrights

On Fri, Sep 15, 2017 at 04:40:28PM -0700, Greg KH wrote: > On Sat, Sep 16, 2017 at 02:31:13AM +0300, Serge Semin wrote: > > Signed-off-by: Serge Semin > > --- > > drivers/usb/misc/usb251xb.c | 1 + > > 1 file changed, 1 insertions(+), 0 deletion(-) > > I can't take patches without any changelog

  1   2   3   4   5   6   7   8   9   10   >