[PATCH net-next 2/5] net: dsa: check VLAN capability of every switch

Now that the VLAN object is propagated to every switch chip of the switch fabric, we can easily ensure that they all support the required VLAN operations before modifying an entry on a single switch. To achieve that, remove the condition skipping other target switches, and add a bitmap of VLAN

[PATCH net-next 2/5] net: dsa: check VLAN capability of every switch

Now that the VLAN object is propagated to every switch chip of the switch fabric, we can easily ensure that they all support the required VLAN operations before modifying an entry on a single switch. To achieve that, remove the condition skipping other target switches, and add a bitmap of VLAN

[GIT] Sparc

1) Fix TLB context wrap races, from Pavel Tatashin. 2) Cure some gcc-7 build issues. 3) Handle invalid setup_hugepagesz command line values properly, from Liam R. Howlett. 4) Copy TSB using the correct address shift for the huge TSB, from Mike Kravetz. Please pull, thanks a lot! The

[GIT] Sparc

1) Fix TLB context wrap races, from Pavel Tatashin. 2) Cure some gcc-7 build issues. 3) Handle invalid setup_hugepagesz command line values properly, from Liam R. Howlett. 4) Copy TSB using the correct address shift for the huge TSB, from Mike Kravetz. Please pull, thanks a lot! The

[GIT] Networking

1) Made TCP congestion control documentation match current reality, from Anmol Sarma. 2) Various build warning and failure fixes from Arnd Bergmann. 3) Fix SKB list leak in ipv6_gso_segment(). 4) Use after free in ravb driver, from Eugeniu Rosca. 5) Don't use udp_poll() in ping protocol

[GIT] Networking

1) Made TCP congestion control documentation match current reality, from Anmol Sarma. 2) Various build warning and failure fixes from Arnd Bergmann. 3) Fix SKB list leak in ipv6_gso_segment(). 4) Use after free in ravb driver, from Eugeniu Rosca. 5) Don't use udp_poll() in ping protocol

Re: [PATCH 3.18 00/33] 3.18.56-stable review

Greg Kroah-Hartman writes: > On Mon, Jun 05, 2017 at 02:01:06PM -0700, kernelci.org bot wrote: >> stable-rc/linux-3.18.y boot: 64 boots: 1 failed, 63 passed >> (v3.18.55-34-g975c7a9adc27) >> >> Full Boot Summary: >>

Re: [PATCH 3.18 00/33] 3.18.56-stable review

Greg Kroah-Hartman writes: > On Mon, Jun 05, 2017 at 02:01:06PM -0700, kernelci.org bot wrote: >> stable-rc/linux-3.18.y boot: 64 boots: 1 failed, 63 passed >> (v3.18.55-34-g975c7a9adc27) >> >> Full Boot Summary: >>

Re: [PATCH 5/7] RISC-V: arch/riscv/lib

On Tue, 06 Jun 2017 02:31:02 PDT (-0700), Arnd Bergmann wrote: > On Tue, Jun 6, 2017 at 6:56 AM, Palmer Dabbelt wrote: >> On Fri, 26 May 2017 02:06:58 PDT (-0700), Arnd Bergmann wrote: >>> On Thu, May 25, 2017 at 3:59 AM, Palmer Dabbelt wrote: On Tue,

Re: [PATCH 5/7] RISC-V: arch/riscv/lib

On Tue, 06 Jun 2017 02:31:02 PDT (-0700), Arnd Bergmann wrote: > On Tue, Jun 6, 2017 at 6:56 AM, Palmer Dabbelt wrote: >> On Fri, 26 May 2017 02:06:58 PDT (-0700), Arnd Bergmann wrote: >>> On Thu, May 25, 2017 at 3:59 AM, Palmer Dabbelt wrote: On Tue, 23 May 2017 04:19:42 PDT (-0700), Arnd

Re: [PATCH 3.18 00/68] 3.18.52-stable review

Alexandre Belloni writes: > Hi, > > On 08/05/2017 at 11:13:51 -0700, Kevin Hilman wrote: >> + relevant soc/board maintainers >> >> kernelci.org bot writes: >> >> > stable-rc/linux-3.18.y boot: 77 boots: 2 failed, 75 passed >> >

Re: [PATCH 3.18 00/68] 3.18.52-stable review

Alexandre Belloni writes: > Hi, > > On 08/05/2017 at 11:13:51 -0700, Kevin Hilman wrote: >> + relevant soc/board maintainers >> >> kernelci.org bot writes: >> >> > stable-rc/linux-3.18.y boot: 77 boots: 2 failed, 75 passed >> > (v3.18.51-69-gdab3331ef5e9) >> > >> > Full Boot Summary: >> >

Re: [PATCH v2] platform/x86: wmi-bmof: New driver to expose embedded Binary WMI MOF metadata

On Tuesday 06 June 2017 19:02:01 Darren Hart wrote: > On Tue, Jun 06, 2017 at 12:04:40PM +0200, Pali Rohár wrote: > > On Monday 05 June 2017 20:16:44 Andy Lutomirski wrote: > > > +#define WMI_BMOF_GUID "05901221-D566-11D1-B2F0-00A0C9062910" > > > +MODULE_ALIAS("wmi:" WMI_BMOF_GUID); > > > >

Re: [PATCH v2] platform/x86: wmi-bmof: New driver to expose embedded Binary WMI MOF metadata

On Tuesday 06 June 2017 19:02:01 Darren Hart wrote: > On Tue, Jun 06, 2017 at 12:04:40PM +0200, Pali Rohár wrote: > > On Monday 05 June 2017 20:16:44 Andy Lutomirski wrote: > > > +#define WMI_BMOF_GUID "05901221-D566-11D1-B2F0-00A0C9062910" > > > +MODULE_ALIAS("wmi:" WMI_BMOF_GUID); > > > >

Re: CLK_OF_DECLARE advice required

On 06/06, Geert Uytterhoeven wrote: > Hi Stephen, > > On Mon, Jun 5, 2017 at 10:13 PM, Stephen Boyd wrote: > > On 06/05, Phil Elwell wrote: > >> That sounds great, but it doesn't match my experience. Let me restate my > >> observations with a bit more detail. > >> > >> In

Re: CLK_OF_DECLARE advice required

On 06/06, Geert Uytterhoeven wrote: > Hi Stephen, > > On Mon, Jun 5, 2017 at 10:13 PM, Stephen Boyd wrote: > > On 06/05, Phil Elwell wrote: > >> That sounds great, but it doesn't match my experience. Let me restate my > >> observations with a bit more detail. > >> > >> In this scenario there

[PATCH 1/3] fs/locks: Use allocation rather than the stack in fcntl_getlk()

Struct file_lock is fairly large, so let's save some space on the stack by using an allocation for struct file_lock in fcntl_getlk(), just as we do for fcntl_setlk(). Signed-off-by: Benjamin Coddington --- fs/locks.c | 46 ++ 1

[PATCH 1/3] fs/locks: Use allocation rather than the stack in fcntl_getlk()

Struct file_lock is fairly large, so let's save some space on the stack by using an allocation for struct file_lock in fcntl_getlk(), just as we do for fcntl_setlk(). Signed-off-by: Benjamin Coddington --- fs/locks.c | 46 ++ 1 file changed, 26

Re: [PATCH v2 1/1] e1000e: Undo e1000e_pm_freeze if __e1000_shutdown fails

On Fri, 2017-06-02 at 14:14 -0400, David Miller wrote: > From: Jani Nikula > Date: Wed, 31 May 2017 18:50:43 +0300 > > > From: Chris Wilson > > > > An error during suspend (e100e_pm_suspend), > > ... > > lead to complete failure: > > ... > >

Re: [PATCH v2 1/1] e1000e: Undo e1000e_pm_freeze if __e1000_shutdown fails

On Fri, 2017-06-02 at 14:14 -0400, David Miller wrote: > From: Jani Nikula > Date: Wed, 31 May 2017 18:50:43 +0300 > > > From: Chris Wilson > > > > An error during suspend (e100e_pm_suspend), > > ... > > lead to complete failure: > > ... > > The unwind failures stems from commit

[PATCH 0/3 v4] Fixups for l_pid

LTP fcntl tests (fcntl11 fcntl14 fcntl17 fcntl19 fcntl20 fcntl21) have been failing for NFSv4 mounts due to an unexpected l_pid. What follows are some fixups: v2: - Rebase onto linux-next - Revert back to using the stack in locks_mandatory_area(), and fixup patch description for 1/3

[PATCH 3/3] fs/locks: Use fs-specific l_pid for remote locks

Now that we're translating fl_pid for F_GETLK and /proc/locks, we need to handle the case where a remote filesystem directly sets fl_pid. In that case, the fl_pid should not be translated into a local pid namespace. If the filesystem implements the lock operation, set a flag to return the lock's

[PATCH 0/3 v4] Fixups for l_pid

LTP fcntl tests (fcntl11 fcntl14 fcntl17 fcntl19 fcntl20 fcntl21) have been failing for NFSv4 mounts due to an unexpected l_pid. What follows are some fixups: v2: - Rebase onto linux-next - Revert back to using the stack in locks_mandatory_area(), and fixup patch description for 1/3

[PATCH 3/3] fs/locks: Use fs-specific l_pid for remote locks

Now that we're translating fl_pid for F_GETLK and /proc/locks, we need to handle the case where a remote filesystem directly sets fl_pid. In that case, the fl_pid should not be translated into a local pid namespace. If the filesystem implements the lock operation, set a flag to return the lock's

[PATCH 2/3] fs/locks: Remove fl_nspid

Since commit c69899a17ca4 "NFSv4: Update of VFS byte range lock must be atomic with the stateid update", NFSv4 has been inserting locks in rpciod worker context. The result is that the file_lock's fl_nspid is the kworker's pid instead of the original userspace pid. The fl_nspid is only used to

[PATCH 2/3] fs/locks: Remove fl_nspid

Since commit c69899a17ca4 "NFSv4: Update of VFS byte range lock must be atomic with the stateid update", NFSv4 has been inserting locks in rpciod worker context. The result is that the file_lock's fl_nspid is the kworker's pid instead of the original userspace pid. The fl_nspid is only used to

Re: [RFC PATCH v2 1/7] mm, oom: refactor select_bad_process() to take memcg as an argument

On Tue, 6 Jun 2017, Roman Gushchin wrote: > Hi David! > > Thank you for sharing this! > > It's very interesting, and it looks like, > it's not that far from what I've suggested. > > So we definitily need to come up with some common solution. > Hi Roman, Yes, definitely. I could post a

Re: [RFC PATCH v2 1/7] mm, oom: refactor select_bad_process() to take memcg as an argument

On Tue, 6 Jun 2017, Roman Gushchin wrote: > Hi David! > > Thank you for sharing this! > > It's very interesting, and it looks like, > it's not that far from what I've suggested. > > So we definitily need to come up with some common solution. > Hi Roman, Yes, definitely. I could post a

Re: [PATCH v3] arch/sparc: support NR_CPUS = 4096

From: Jane Chu Date: Tue, 6 Jun 2017 14:32:29 -0600 > Linux SPARC64 limits NR_CPUS to 4064 because init_cpu_send_mondo_info() > only allocates a single page for NR_CPUS mondo entries. Thus we cannot > use all 4096 CPUs on some SPARC platforms. > > To fix, allocate

Re: [PATCH v3] arch/sparc: support NR_CPUS = 4096

From: Jane Chu Date: Tue, 6 Jun 2017 14:32:29 -0600 > Linux SPARC64 limits NR_CPUS to 4064 because init_cpu_send_mondo_info() > only allocates a single page for NR_CPUS mondo entries. Thus we cannot > use all 4096 CPUs on some SPARC platforms. > > To fix, allocate (2^order) pages where order

Re: [PATCH 2/3] fs/locks: Remove fl_nspid

On 6 Jun 2017, at 14:57, Benjamin Coddington wrote: On 6 Jun 2017, at 14:25, Jeff Layton wrote: On Tue, 2017-06-06 at 14:00 -0400, Jeff Layton wrote: On Tue, 2017-06-06 at 13:19 -0400, Benjamin Coddington wrote: Since commit c69899a17ca4 "NFSv4: Update of VFS byte range lock must be atomic

Re: [PATCH 2/3] fs/locks: Remove fl_nspid

On 6 Jun 2017, at 14:57, Benjamin Coddington wrote: On 6 Jun 2017, at 14:25, Jeff Layton wrote: On Tue, 2017-06-06 at 14:00 -0400, Jeff Layton wrote: On Tue, 2017-06-06 at 13:19 -0400, Benjamin Coddington wrote: Since commit c69899a17ca4 "NFSv4: Update of VFS byte range lock must be atomic

Re: [RFC 11/55] KVM: arm64: Emulate taking an exception to the guest hypervisor

Hi Bandan, On Tue, Jun 6, 2017 at 4:21 PM, Bandan Das wrote: > Jintack Lim writes: > >> Emulate taking an exception to the guest hypervisor running in the >> virtual EL2 as described in ARM ARM AArch64.TakeException(). > > ARM newbie here, I keep

Re: [RFC 11/55] KVM: arm64: Emulate taking an exception to the guest hypervisor

Hi Bandan, On Tue, Jun 6, 2017 at 4:21 PM, Bandan Das wrote: > Jintack Lim writes: > >> Emulate taking an exception to the guest hypervisor running in the >> virtual EL2 as described in ARM ARM AArch64.TakeException(). > > ARM newbie here, I keep thinking of ARM ARM as a typo ;) ARM ARM means

Re: [PATCH 6/7] RISC-V: arch/riscv/kernel

On Tue, 06 Jun 2017 02:03:51 PDT (-0700), Arnd Bergmann wrote: > On Tue, Jun 6, 2017 at 6:56 AM, Palmer Dabbelt wrote: >> On Thu, 25 May 2017 12:51:54 PDT (-0700), Arnd Bergmann wrote: >>> On Thu, May 25, 2017 at 3:59 AM, Palmer Dabbelt wrote: On Mon,

Re: [PATCH 6/7] RISC-V: arch/riscv/kernel

On Tue, 06 Jun 2017 02:03:51 PDT (-0700), Arnd Bergmann wrote: > On Tue, Jun 6, 2017 at 6:56 AM, Palmer Dabbelt wrote: >> On Thu, 25 May 2017 12:51:54 PDT (-0700), Arnd Bergmann wrote: >>> On Thu, May 25, 2017 at 3:59 AM, Palmer Dabbelt wrote: On Mon, 22 May 2017 19:11:35 PDT (-0700),

Re: [PATCH 6/7] RISC-V: arch/riscv/kernel

On Tue, 06 Jun 2017 02:01:23 PDT (-0700), Arnd Bergmann wrote: > On Sat, Jun 3, 2017 at 1:56 AM, Palmer Dabbelt wrote: >> On Tue, 23 May 2017 06:35:23 PDT (-0700), Arnd Bergmann wrote: +IRQCHIP_DECLARE(riscv, "riscv,cpu-intc", riscv_intc_init); >>> If you don't care about

Re: [PATCH 6/7] RISC-V: arch/riscv/kernel

On Tue, 06 Jun 2017 02:01:23 PDT (-0700), Arnd Bergmann wrote: > On Sat, Jun 3, 2017 at 1:56 AM, Palmer Dabbelt wrote: >> On Tue, 23 May 2017 06:35:23 PDT (-0700), Arnd Bergmann wrote: +IRQCHIP_DECLARE(riscv, "riscv,cpu-intc", riscv_intc_init); >>> If you don't care about LPC/ISA devices,

Re: [PATCH 2/7] RISC-V: arch/riscv Makefile and Kconfigs

On Tue, 06 Jun 2017 02:20:50 PDT (-0700), Arnd Bergmann wrote: > On Tue, Jun 6, 2017 at 6:56 AM, Palmer Dabbelt wrote: >> On Mon, 29 May 2017 04:17:40 PDT (-0700), Arnd Bergmann wrote: >>> On Sat, May 27, 2017 at 2:57 AM, Palmer Dabbelt wrote: On Tue,

Re: [PATCH 2/7] RISC-V: arch/riscv Makefile and Kconfigs

On Tue, 06 Jun 2017 02:20:50 PDT (-0700), Arnd Bergmann wrote: > On Tue, Jun 6, 2017 at 6:56 AM, Palmer Dabbelt wrote: >> On Mon, 29 May 2017 04:17:40 PDT (-0700), Arnd Bergmann wrote: >>> On Sat, May 27, 2017 at 2:57 AM, Palmer Dabbelt wrote: On Tue, 23 May 2017 04:46:22 PDT (-0700), Arnd

[patch resend] compiler, clang: suppress warning for unused static inline functions

GCC explicitly does not warn for unused static inline functions for -Wunused-function. The manual states: Warn whenever a static function is declared but not defined or a non-inline static function is unused. Clang does warn for static inline functions that are unused. It turns

[patch resend] compiler, clang: suppress warning for unused static inline functions

GCC explicitly does not warn for unused static inline functions for -Wunused-function. The manual states: Warn whenever a static function is declared but not defined or a non-inline static function is unused. Clang does warn for static inline functions that are unused. It turns

Re: [PATCH v4] net: don't call strlen on non-terminated string in dev_set_alias()

From: Alexander Potapenko Date: Tue, 6 Jun 2017 15:56:54 +0200 > KMSAN reported a use of uninitialized memory in dev_set_alias(), > which was caused by calling strlcpy() (which in turn called strlen()) > on the user-supplied non-terminated string. > > Signed-off-by:

Re: [PATCH v4] net: don't call strlen on non-terminated string in dev_set_alias()

From: Alexander Potapenko Date: Tue, 6 Jun 2017 15:56:54 +0200 > KMSAN reported a use of uninitialized memory in dev_set_alias(), > which was caused by calling strlcpy() (which in turn called strlen()) > on the user-supplied non-terminated string. > > Signed-off-by: Alexander Potapenko We

[PATCH v3] arch/sparc: support NR_CPUS = 4096

Linux SPARC64 limits NR_CPUS to 4064 because init_cpu_send_mondo_info() only allocates a single page for NR_CPUS mondo entries. Thus we cannot use all 4096 CPUs on some SPARC platforms. To fix, allocate (2^order) pages where order is set according to the size of cpu_list for possible cpus. Since

[PATCH v3] arch/sparc: support NR_CPUS = 4096

Linux SPARC64 limits NR_CPUS to 4064 because init_cpu_send_mondo_info() only allocates a single page for NR_CPUS mondo entries. Thus we cannot use all 4096 CPUs on some SPARC platforms. To fix, allocate (2^order) pages where order is set according to the size of cpu_list for possible cpus. Since

Re: [PATCH] net: stmmac: fix a broken u32 less than zero check

From: Colin King Date: Tue, 6 Jun 2017 14:10:49 +0100 > From: Colin Ian King > > The check that queue is less or equal to zero is always true > because queue is a u32; queue is decremented and will wrap around > and never go -ve. Fix this by

Re: [PATCH] net: stmmac: fix a broken u32 less than zero check

From: Colin King Date: Tue, 6 Jun 2017 14:10:49 +0100 > From: Colin Ian King > > The check that queue is less or equal to zero is always true > because queue is a u32; queue is decremented and will wrap around > and never go -ve. Fix this by making queue an int. > > Detected by CoverityScan,

Re: [PATCH net-next] tun: use symmetric hash

From: Jason Wang Date: Tue, 6 Jun 2017 14:09:49 +0800 > Tun actually expects a symmetric hash for queue selecting to work > correctly, otherwise packets belongs to a single flow may be > redirected to the wrong queue. So this patch switch to use >

Re: [PATCH net-next] tun: use symmetric hash

From: Jason Wang Date: Tue, 6 Jun 2017 14:09:49 +0800 > Tun actually expects a symmetric hash for queue selecting to work > correctly, otherwise packets belongs to a single flow may be > redirected to the wrong queue. So this patch switch to use > __skb_get_hash_symmetric(). > > Signed-off-by:

Re: [PATCH net] net: stmmac: fix completely hung TX when using TSO

From: Niklas Cassel Date: Tue, 6 Jun 2017 09:25:00 +0200 > stmmac_tso_allocator can fail to set the Last Descriptor bit > on a descriptor that actually was the last descriptor. > > This happens when the buffer of the last descriptor ends > up having a size of exactly

Re: [PATCH net] net: stmmac: fix completely hung TX when using TSO

From: Niklas Cassel Date: Tue, 6 Jun 2017 09:25:00 +0200 > stmmac_tso_allocator can fail to set the Last Descriptor bit > on a descriptor that actually was the last descriptor. > > This happens when the buffer of the last descriptor ends > up having a size of exactly TSO_MAX_BUFF_SIZE. > >

Re: [PATCH v2 3/4] net: macb: macb.c changed to macb_main.c

On Tue, Jun 06, 2017 at 03:00:15PM -0400, David Miller wrote: > He's adjusting the Makefile so that it build macb_main.c into macb.o Duh, sorry, brain shutting down... Thanks, Richard

Re: [PATCH v2 3/4] net: macb: macb.c changed to macb_main.c

On Tue, Jun 06, 2017 at 03:00:15PM -0400, David Miller wrote: > He's adjusting the Makefile so that it build macb_main.c into macb.o Duh, sorry, brain shutting down... Thanks, Richard

Re: [PATCH 1/4] mfd: da903x: Make it explicitly non-modular

[RE: [PATCH 1/4] mfd: da903x: Make it explicitly non-modular] On 06/06/2017 (Tue 15:27) Steve Twiss wrote: > Hi Paul, > > On 05 June 2017 20:30, Paul Gortmaker wrote: > > > Subject: Re: [PATCH 1/4] mfd: da903x: Make it explicitly non-modular > > > > [RE: [PATCH 1/4] mfd: da903x: Make it

Re: [PATCH 1/4] mfd: da903x: Make it explicitly non-modular

[RE: [PATCH 1/4] mfd: da903x: Make it explicitly non-modular] On 06/06/2017 (Tue 15:27) Steve Twiss wrote: > Hi Paul, > > On 05 June 2017 20:30, Paul Gortmaker wrote: > > > Subject: Re: [PATCH 1/4] mfd: da903x: Make it explicitly non-modular > > > > [RE: [PATCH 1/4] mfd: da903x: Make it

Re: [RFC 11/55] KVM: arm64: Emulate taking an exception to the guest hypervisor

Jintack Lim writes: > Emulate taking an exception to the guest hypervisor running in the > virtual EL2 as described in ARM ARM AArch64.TakeException(). ARM newbie here, I keep thinking of ARM ARM as a typo ;) ... > +static inline int kvm_inject_nested_sync(struct

Re: [RFC 11/55] KVM: arm64: Emulate taking an exception to the guest hypervisor

Jintack Lim writes: > Emulate taking an exception to the guest hypervisor running in the > virtual EL2 as described in ARM ARM AArch64.TakeException(). ARM newbie here, I keep thinking of ARM ARM as a typo ;) ... > +static inline int kvm_inject_nested_sync(struct kvm_vcpu *vcpu, u64 esr_el2) >

Re: [RFC 10/55] KVM: arm64: Synchronize EL1 system registers on virtual EL2 entry and exit

Jintack Lim writes: > From: Christoffer Dall > > When running in virtual EL2 we use the shadow EL1 systerm register array > for the save/restore process, so that hardware and especially the memory > subsystem behaves as code written for EL2

Re: [RFC 10/55] KVM: arm64: Synchronize EL1 system registers on virtual EL2 entry and exit

Jintack Lim writes: > From: Christoffer Dall > > When running in virtual EL2 we use the shadow EL1 systerm register array > for the save/restore process, so that hardware and especially the memory > subsystem behaves as code written for EL2 expects while really running > in EL1. > > This works

Re: [xfstests PATCH v3 1/5] generic: add a writeback error handling test

On Tue, 2017-06-06 at 10:17 -0700, Darrick J. Wong wrote: > On Tue, Jun 06, 2017 at 08:23:25PM +0800, Eryu Guan wrote: > > On Tue, Jun 06, 2017 at 06:15:57AM -0400, Jeff Layton wrote: > > > On Tue, 2017-06-06 at 16:58 +0800, Eryu Guan wrote: > > > > On Wed, May 31, 2017 at 09:08:16AM -0400, Jeff

Re: [xfstests PATCH v3 1/5] generic: add a writeback error handling test

On Tue, 2017-06-06 at 10:17 -0700, Darrick J. Wong wrote: > On Tue, Jun 06, 2017 at 08:23:25PM +0800, Eryu Guan wrote: > > On Tue, Jun 06, 2017 at 06:15:57AM -0400, Jeff Layton wrote: > > > On Tue, 2017-06-06 at 16:58 +0800, Eryu Guan wrote: > > > > On Wed, May 31, 2017 at 09:08:16AM -0400, Jeff

Re: [PATCH V2 1/2] leds: leds-qti-rgb: Add LED driver for QTI TRI_LED module

Hi! > >> Generally I came to a conclusion that it will be best to register > >> additional LED RGB class device in an addition to three LED class > >> devices representing each color. In order to avoid hard to solve > >> locking problems I propose to allow for simultaneous access to LED > >>

Re: [PATCH V2 1/2] leds: leds-qti-rgb: Add LED driver for QTI TRI_LED module

Hi! > >> Generally I came to a conclusion that it will be best to register > >> additional LED RGB class device in an addition to three LED class > >> devices representing each color. In order to avoid hard to solve > >> locking problems I propose to allow for simultaneous access to LED > >>

Re: [PATCH 1/2] hsr: fix coding style issues

Please do not mix cleanups with legitimate bug fixes. Also, when posting a multi-patch series, you must always provide an appropriate "[PATCH 0/N]" header posting that describes what you series is doing at a high level, how it is doing it, and why it is doing it that way. For this, submit the

Re: [PATCH 1/2] hsr: fix coding style issues

Please do not mix cleanups with legitimate bug fixes. Also, when posting a multi-patch series, you must always provide an appropriate "[PATCH 0/N]" header posting that describes what you series is doing at a high level, how it is doing it, and why it is doing it that way. For this, submit the

Re: [PATCH V2 1/2] leds: leds-qti-rgb: Add LED driver for QTI TRI_LED module

Hi, On 06/05/2017 11:16 PM, Pavel Machek wrote: > Hi! > >> Generally I came to a conclusion that it will be best to register >> additional LED RGB class device in an addition to three LED class >> devices representing each color. In order to avoid hard to solve >> locking problems I propose to

Re: [PATCH V2 1/2] leds: leds-qti-rgb: Add LED driver for QTI TRI_LED module

Hi, On 06/05/2017 11:16 PM, Pavel Machek wrote: > Hi! > >> Generally I came to a conclusion that it will be best to register >> additional LED RGB class device in an addition to three LED class >> devices representing each color. In order to avoid hard to solve >> locking problems I propose to

Re: [PATCH 00/26] Fixing wait, exit, ptrace, exec, and CLONE_THREAD

On Tue, Jun 6, 2017 at 12:01 PM, Eric W. Biederman wrote: > > I am posting this patches in the hope of some review of the strategy I > am taking and to let the individual patches be reviewed. I'm trying to look through these, and finding (as usual) that the signal handling

Re: [PATCH 00/26] Fixing wait, exit, ptrace, exec, and CLONE_THREAD

On Tue, Jun 6, 2017 at 12:01 PM, Eric W. Biederman wrote: > > I am posting this patches in the hope of some review of the strategy I > am taking and to let the individual patches be reviewed. I'm trying to look through these, and finding (as usual) that the signal handling and exit code is

[PATCH] platform/x86/acer-wmi: Detect RF Button capability

If a machine reports a RF Button in the communication button device bitmap, we need to remove it before calling Get Device Status otherwise it will return the "Undefined device" (0xE2) error code. Although this may be a BIOS bug, we don't really need to get or set the RF Button status. The status

[PATCH] platform/x86/acer-wmi: Detect RF Button capability

If a machine reports a RF Button in the communication button device bitmap, we need to remove it before calling Get Device Status otherwise it will return the "Undefined device" (0xE2) error code. Although this may be a BIOS bug, we don't really need to get or set the RF Button status. The status

Re: [PATCH net-next] net: dsa: mv88e6xxx: fix 6085 frame mode masking

From: Vivien Didelot Date: Mon, 5 Jun 2017 18:17:16 -0400 > The register bits used for the frame mode were masked with DSA (0x1) > instead of the mask value (0x3) in the 6085 implementation of > port_set_frame_mode. Fix this. > > Fixes: 56995cbc3540 ("net:

Re: [PATCH net-next] net: dsa: mv88e6xxx: fix 6085 frame mode masking

From: Vivien Didelot Date: Mon, 5 Jun 2017 18:17:16 -0400 > The register bits used for the frame mode were masked with DSA (0x1) > instead of the mask value (0x3) in the 6085 implementation of > port_set_frame_mode. Fix this. > > Fixes: 56995cbc3540 ("net: dsa: mv88e6xxx: Refactor CPU and DSA

Re: [PATCH v2] checkpatch: Change format of --color argument to --color[=WHEN]

On Tue, 2017-06-06 at 19:56 +, John Brooks wrote: > On Tue, Jun 06, 2017 at 12:21:22PM -0700, Joe Perches wrote: > > On Tue, 2017-06-06 at 13:07 -0400, John Brooks wrote: > > > The boolean --color argument did not offer the ability to force colourized > > > output even if stdout is not a

Re: [PATCH v2] checkpatch: Change format of --color argument to --color[=WHEN]

On Tue, 2017-06-06 at 19:56 +, John Brooks wrote: > On Tue, Jun 06, 2017 at 12:21:22PM -0700, Joe Perches wrote: > > On Tue, 2017-06-06 at 13:07 -0400, John Brooks wrote: > > > The boolean --color argument did not offer the ability to force colourized > > > output even if stdout is not a

Re: [PATCH V2] xen-evtchn: Bind dyn evtchn:qemu-dm interrupt to next online VCPU

Hi Anoob, [auto build test ERROR on xen-tip/linux-next] [also build test ERROR on v4.12-rc4 next-20170606] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Anoob-Soman/xen-evtchn-Bind-dyn-evtchn

Re: [PATCH V2] xen-evtchn: Bind dyn evtchn:qemu-dm interrupt to next online VCPU

Hi Anoob, [auto build test ERROR on xen-tip/linux-next] [also build test ERROR on v4.12-rc4 next-20170606] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Anoob-Soman/xen-evtchn-Bind-dyn-evtchn

Re: [PATCH 03/26] signal: Do not perform permission checks when sending pdeath_signal

On Tue, Jun 6, 2017 at 12:03 PM, Eric W. Biederman wrote: > > As this is more permisssive there is no chance anything will break. Actually, I do worry about the security issues here. The thing is, the parent may be some system daemon that wants to catch SIGCHLD, but we've

Re: [PATCH 03/26] signal: Do not perform permission checks when sending pdeath_signal

On Tue, Jun 6, 2017 at 12:03 PM, Eric W. Biederman wrote: > > As this is more permisssive there is no chance anything will break. Actually, I do worry about the security issues here. The thing is, the parent may be some system daemon that wants to catch SIGCHLD, but we've used prctl and changed

Re: [PATCH v2] checkpatch: Change format of --color argument to --color[=WHEN]

On Tue, Jun 06, 2017 at 12:21:22PM -0700, Joe Perches wrote: > On Tue, 2017-06-06 at 13:07 -0400, John Brooks wrote: > > The boolean --color argument did not offer the ability to force colourized > > output even if stdout is not a terminal. Change the format of the argument > > to the familiar

Re: [PATCH v2] checkpatch: Change format of --color argument to --color[=WHEN]

On Tue, Jun 06, 2017 at 12:21:22PM -0700, Joe Perches wrote: > On Tue, 2017-06-06 at 13:07 -0400, John Brooks wrote: > > The boolean --color argument did not offer the ability to force colourized > > output even if stdout is not a terminal. Change the format of the argument > > to the familiar

Applied "ASoC: sun8i-codec-analog: prepare a mixer control/widget/route set for V3s" to the asoc tree

The patch ASoC: sun8i-codec-analog: prepare a mixer control/widget/route set for V3s has been applied to the asoc tree at git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git All being well this means that it will be integrated into the linux-next tree (usually sometime in

Applied "ASoC: sun8i-codec-analog: prepare a mixer control/widget/route set for V3s" to the asoc tree

The patch ASoC: sun8i-codec-analog: prepare a mixer control/widget/route set for V3s has been applied to the asoc tree at git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git All being well this means that it will be integrated into the linux-next tree (usually sometime in

Re: [PATCH 6/7] perf report: mark inlined frames in output by " (inlined)" suffix

Em Tue, Jun 06, 2017 at 09:26:47AM +0200, Milian Wolff escreveu: > On Tuesday, June 6, 2017 3:33:49 AM CEST Namhyung Kim wrote: > > On Sat, Jun 3, 2017 at 10:51 PM, Milian Wolff wrote: > > > The current API seems to pass the data around mostly using the > > > addr_location

Re: [PATCH 6/7] perf report: mark inlined frames in output by " (inlined)" suffix

Em Tue, Jun 06, 2017 at 09:26:47AM +0200, Milian Wolff escreveu: > On Tuesday, June 6, 2017 3:33:49 AM CEST Namhyung Kim wrote: > > On Sat, Jun 3, 2017 at 10:51 PM, Milian Wolff wrote: > > > The current API seems to pass the data around mostly using the > > > addr_location struct, which is

Re: [PATCH] x86/mm/hotplug: fix BUG_ON() after hotremove

Thanks Jerome! This indeed fixes the bug I reported. Tested-by: Logan Gunthorpe Logan On 06/06/17 11:35 AM, Jérôme Glisse wrote: > With commit af2cf278ef4f we no longer free pud so that we > do not have synchronize all pgd on hotremove/vfree. But the > new 5 level page

Re: [PATCH] x86/mm/hotplug: fix BUG_ON() after hotremove

Thanks Jerome! This indeed fixes the bug I reported. Tested-by: Logan Gunthorpe Logan On 06/06/17 11:35 AM, Jérôme Glisse wrote: > With commit af2cf278ef4f we no longer free pud so that we > do not have synchronize all pgd on hotremove/vfree. But the > new 5 level page table code re-added

Re: [PATCH 0/4][V3] Improve watchdog config for arch watchdogs

Hi Don, Nicholas, On 6/6/2017 11:08 AM, Don Zickus wrote: (adding Babu) On Tue, May 30, 2017 at 11:26:55AM +1000, Nicholas Piggin wrote: Since last time: - Have the perf based hardlockup detector use arch_touch_nmi_watchdog() rather than hld_touch_nmi_watchdog(). This changes direction

Re: [PATCH 0/4][V3] Improve watchdog config for arch watchdogs

Hi Don, Nicholas, On 6/6/2017 11:08 AM, Don Zickus wrote: (adding Babu) On Tue, May 30, 2017 at 11:26:55AM +1000, Nicholas Piggin wrote: Since last time: - Have the perf based hardlockup detector use arch_touch_nmi_watchdog() rather than hld_touch_nmi_watchdog(). This changes direction

Re: [PATCH v2] arm: eBPF JIT compiler

Hi Russell, Alexei, David, Daniel, kees, Any update on this patch moving forward? Best, Shubham Bansal On Wed, May 31, 2017 at 12:49 AM, Kees Cook wrote: > Forwarding this to net-dev and eBPF folks, who weren't on CC... > > -Kees > > On Thu, May 25, 2017 at 4:13 PM,

Re: [PATCH v2] arm: eBPF JIT compiler

Hi Russell, Alexei, David, Daniel, kees, Any update on this patch moving forward? Best, Shubham Bansal On Wed, May 31, 2017 at 12:49 AM, Kees Cook wrote: > Forwarding this to net-dev and eBPF folks, who weren't on CC... > > -Kees > > On Thu, May 25, 2017 at 4:13 PM, Shubham Bansal > wrote: >>

Re: [PATCH 4/4] ARM: multi_v7_defconfig: Switch AXP20x driver from module to built-in

On Mon, May 22, 2017 at 12:44 AM, Maxime Ripard wrote: > Hi Kevin, > > On Thu, May 18, 2017 at 11:59:50AM -0700, Kevin Hilman wrote: >> On Fri, Mar 17, 2017 at 10:39 AM, Kevin Hilman wrote: >> > On Fri, Feb 10, 2017 at 12:42 AM, Maxime

Re: [PATCH 4/4] ARM: multi_v7_defconfig: Switch AXP20x driver from module to built-in

On Mon, May 22, 2017 at 12:44 AM, Maxime Ripard wrote: > Hi Kevin, > > On Thu, May 18, 2017 at 11:59:50AM -0700, Kevin Hilman wrote: >> On Fri, Mar 17, 2017 at 10:39 AM, Kevin Hilman wrote: >> > On Fri, Feb 10, 2017 at 12:42 AM, Maxime Ripard >> > wrote: >> >> On Wed, Feb 08, 2017 at 11:09:31PM

Applied "ASoC: sun8i-codec-analog: add support for V3s SoC" to the asoc tree

The patch ASoC: sun8i-codec-analog: add support for V3s SoC has been applied to the asoc tree at git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours) and sent

Applied "ASoC: sun8i-codec-analog: add support for V3s SoC" to the asoc tree

The patch ASoC: sun8i-codec-analog: add support for V3s SoC has been applied to the asoc tree at git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours) and sent

Re: [PATCH v4 0/3] USB Audio Gadget refactoring

On Tue, Jun 6, 2017 at 12:41 PM, Felipe Balbi wrote: > > Hi, > > Greg KH writes: >>> > I'm OK with dropping legacy f_uac1 implementation. >>> > >>> > Another idea I was thinking about is to implement simple in-kernel >>> > driver which will do the

Re: [PATCH v4 0/3] USB Audio Gadget refactoring

On Tue, Jun 6, 2017 at 12:41 PM, Felipe Balbi wrote: > > Hi, > > Greg KH writes: >>> > I'm OK with dropping legacy f_uac1 implementation. >>> > >>> > Another idea I was thinking about is to implement simple in-kernel >>> > driver which will do the same as existing alsaloop tool userspace >>> >

Re: [PATCH V2] xen-evtchn: Bind dyn evtchn:qemu-dm interrupt to next online VCPU

> > /* Rebind an evtchn so that it gets delivered to a specific cpu */ > -static int rebind_irq_to_cpu(unsigned irq, unsigned tcpu) > +int xen_rebind_evtchn_to_cpu(int evtchn, unsigned tcpu) > { > struct evtchn_bind_vcpu bind_vcpu; > - int evtchn = evtchn_from_irq(irq); > int

Re: [PATCH V2] xen-evtchn: Bind dyn evtchn:qemu-dm interrupt to next online VCPU

> > /* Rebind an evtchn so that it gets delivered to a specific cpu */ > -static int rebind_irq_to_cpu(unsigned irq, unsigned tcpu) > +int xen_rebind_evtchn_to_cpu(int evtchn, unsigned tcpu) > { > struct evtchn_bind_vcpu bind_vcpu; > - int evtchn = evtchn_from_irq(irq); > int

<    1   2   3   4   5   6   7   8   9   10   >