Re: [PATCH 1/2] powercap/rapl: handle missing msrs

On Monday, June 13, 2016 11:53:10 AM jacob wrote: > Hi Rafael, > > Any feedback? It that is OK, can you take this patch independent of the > second patch (which is going into tip tree)? I'll do that. Thanks, Rafael

Re: [PATCH 1/2] powercap/rapl: handle missing msrs

On Monday, June 13, 2016 11:53:10 AM jacob wrote: > Hi Rafael, > > Any feedback? It that is OK, can you take this patch independent of the > second patch (which is going into tip tree)? I'll do that. Thanks, Rafael

[PATCH 4/7] asus-wmi: Add quirk_no_rfkill for the Asus U303LB

The Asus U303LB has an airplane-mode indicator LED and the WMI WLAN user bit set, so asus-wmi uses ASUS_WMI_DEVID_WLAN_LED (0x00010002) to store the wlan state, which has a side-effect of driving the airplane mode indicator LED in an inverted fashion. quirk_no_rfkill prevents asus-wmi from

[PATCH 4/7] asus-wmi: Add quirk_no_rfkill for the Asus U303LB

The Asus U303LB has an airplane-mode indicator LED and the WMI WLAN user bit set, so asus-wmi uses ASUS_WMI_DEVID_WLAN_LED (0x00010002) to store the wlan state, which has a side-effect of driving the airplane mode indicator LED in an inverted fashion. quirk_no_rfkill prevents asus-wmi from

[PATCH v8 4/5] ptr_ring: resize support

This adds ring resize support. Seems to be necessary as users such as tun allow userspace control over queue size. If resize is used, this costs us ability to peek at queue without consumer lock - should not be a big deal as peek and consumer are usually run on the same CPU. If ring is made

[PATCH v8 4/5] ptr_ring: resize support

This adds ring resize support. Seems to be necessary as users such as tun allow userspace control over queue size. If resize is used, this costs us ability to peek at queue without consumer lock - should not be a big deal as peek and consumer are usually run on the same CPU. If ring is made

[PATCH v8 5/5] skb_array: resize support

Update skb_array after ptr_ring API changes. Signed-off-by: Michael S. Tsirkin --- include/linux/skb_array.h | 33 + 1 file changed, 29 insertions(+), 4 deletions(-) diff --git a/include/linux/skb_array.h b/include/linux/skb_array.h index

[PATCH v8 5/5] skb_array: resize support

Update skb_array after ptr_ring API changes. Signed-off-by: Michael S. Tsirkin --- include/linux/skb_array.h | 33 + 1 file changed, 29 insertions(+), 4 deletions(-) diff --git a/include/linux/skb_array.h b/include/linux/skb_array.h index c4c0902..678bfbf 100644

Re: [PATCH v16 6/6] ARM: socfpga: fpga bridge driver support

On Fri, 10 Jun 2016, Trent Piepho wrote: > On Fri, 2016-02-05 at 15:30 -0600, at...@opensource.altera.com wrote: > > Supports Altera SOCFPGA bridges: > > * fpga2sdram > > * fpga2hps > > * hps2fpga > > * lwhps2fpga > > > > Allows enabling/disabling the bridges through the FPGA > > Bridge

Re: [PATCH v16 6/6] ARM: socfpga: fpga bridge driver support

On Fri, 10 Jun 2016, Trent Piepho wrote: > On Fri, 2016-02-05 at 15:30 -0600, at...@opensource.altera.com wrote: > > Supports Altera SOCFPGA bridges: > > * fpga2sdram > > * fpga2hps > > * hps2fpga > > * lwhps2fpga > > > > Allows enabling/disabling the bridges through the FPGA > > Bridge

[PATCH v8 2/5] ptr_ring: ring test

Add ringtest based unit test for ptr ring. Signed-off-by: Michael S. Tsirkin --- tools/virtio/ringtest/ptr_ring.c | 192 +++ tools/virtio/ringtest/Makefile | 5 +- 2 files changed, 196 insertions(+), 1 deletion(-) create mode 100644

[PATCH v8 2/5] ptr_ring: ring test

Add ringtest based unit test for ptr ring. Signed-off-by: Michael S. Tsirkin --- tools/virtio/ringtest/ptr_ring.c | 192 +++ tools/virtio/ringtest/Makefile | 5 +- 2 files changed, 196 insertions(+), 1 deletion(-) create mode 100644

Re: [PATCH v6 09/11] cpuidle/powernv: Use CPUIDLE_STATE_MAX instead of MAX_POWERNV_IDLE_STATES

On Monday, June 13, 2016 05:01:50 PM Daniel Lezcano wrote: > On Wed, Jun 08, 2016 at 11:54:29AM -0500, Shreyas B. Prabhu wrote: > > Use cpuidle's CPUIDLE_STATE_MAX macro instead of powernv specific > > MAX_POWERNV_IDLE_STATES. > > > > Cc: Rafael J. Wysocki > > Cc:

[PATCH v8 0/5] skb_array: array based FIFO for skbs

This is in response to the proposal by Jason to make tun rx packet queue lockless using a circular buffer. My testing seems to show that at least for the common usecase in networking, which isn't lockless, circular buffer with indices does not perform that well, because each index access causes a

[PATCH v8 1/5] ptr_ring: array based FIFO for pointers

A simple array based FIFO of pointers. Intended for net stack which commonly has a single consumer/producer. Signed-off-by: Michael S. Tsirkin --- include/linux/ptr_ring.h | 264 +++ 1 file changed, 264 insertions(+) create mode

Re: [PATCH v6 09/11] cpuidle/powernv: Use CPUIDLE_STATE_MAX instead of MAX_POWERNV_IDLE_STATES

On Monday, June 13, 2016 05:01:50 PM Daniel Lezcano wrote: > On Wed, Jun 08, 2016 at 11:54:29AM -0500, Shreyas B. Prabhu wrote: > > Use cpuidle's CPUIDLE_STATE_MAX macro instead of powernv specific > > MAX_POWERNV_IDLE_STATES. > > > > Cc: Rafael J. Wysocki > > Cc: Daniel Lezcano > > Cc:

[PATCH v8 0/5] skb_array: array based FIFO for skbs

This is in response to the proposal by Jason to make tun rx packet queue lockless using a circular buffer. My testing seems to show that at least for the common usecase in networking, which isn't lockless, circular buffer with indices does not perform that well, because each index access causes a

[PATCH v8 1/5] ptr_ring: array based FIFO for pointers

A simple array based FIFO of pointers. Intended for net stack which commonly has a single consumer/producer. Signed-off-by: Michael S. Tsirkin --- include/linux/ptr_ring.h | 264 +++ 1 file changed, 264 insertions(+) create mode 100644

Re: [PATCH] cpufreq: conservative: Do not use transition notifications

On Monday, June 13, 2016 08:58:34 PM Viresh Kumar wrote: > On 13-06-16, 15:36, Rafael J. Wysocki wrote: > > From: Rafael J. Wysocki > > Subject: [PATCH v2] cpufreq: conservative: Do not use transition > > notifications > > > > The conservative governor registers a

Re: [PATCH] cpufreq: conservative: Do not use transition notifications

On Monday, June 13, 2016 08:58:34 PM Viresh Kumar wrote: > On 13-06-16, 15:36, Rafael J. Wysocki wrote: > > From: Rafael J. Wysocki > > Subject: [PATCH v2] cpufreq: conservative: Do not use transition > > notifications > > > > The conservative governor registers a transition notifier so it > >

Re: [RFC 18/18] proc: present VM_LOCKED memory in /proc/self/maps

On Mon, Jun 13, 2016 at 10:44:25PM +0300, Topi Miettinen wrote: > Add a flag to /proc/self/maps to show that the memory area is locked. > > Signed-off-by: Topi Miettinen > --- > fs/proc/task_mmu.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git

Re: [RFC 18/18] proc: present VM_LOCKED memory in /proc/self/maps

On Mon, Jun 13, 2016 at 10:44:25PM +0300, Topi Miettinen wrote: > Add a flag to /proc/self/maps to show that the memory area is locked. > > Signed-off-by: Topi Miettinen > --- > fs/proc/task_mmu.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/fs/proc/task_mmu.c

Re: [RFC 18/18] proc: present VM_LOCKED memory in /proc/self/maps

On 06/13/16 20:43, Kees Cook wrote: > On Mon, Jun 13, 2016 at 10:44:25PM +0300, Topi Miettinen wrote: >> Add a flag to /proc/self/maps to show that the memory area is locked. >> >> Signed-off-by: Topi Miettinen >> --- >> fs/proc/task_mmu.c | 3 ++- >> 1 file changed, 2

Re: [RFC 18/18] proc: present VM_LOCKED memory in /proc/self/maps

On 06/13/16 20:43, Kees Cook wrote: > On Mon, Jun 13, 2016 at 10:44:25PM +0300, Topi Miettinen wrote: >> Add a flag to /proc/self/maps to show that the memory area is locked. >> >> Signed-off-by: Topi Miettinen >> --- >> fs/proc/task_mmu.c | 3 ++- >> 1 file changed, 2 insertions(+), 1

[RFC] serial: 8250: fix regression in 8250 uart driver

Hi Andy, I saw that you have discovered that commit ec5a11a91eec ("serial: 8250: Validate dmaengine rx chan meets requirements") introduced a regression in the 8250 uart driver. For SoCFPGA platform, I am seeing this error: [5.541751] ttyS0 - failed to request DMA Reverting the commit

[RFC] serial: 8250: fix regression in 8250 uart driver

Hi Andy, I saw that you have discovered that commit ec5a11a91eec ("serial: 8250: Validate dmaengine rx chan meets requirements") introduced a regression in the 8250 uart driver. For SoCFPGA platform, I am seeing this error: [5.541751] ttyS0 - failed to request DMA Reverting the commit

Re: [PATCH 00/14] run seccomp after ptrace

(Oops, forgot to send this series through the lsm list...) On Thu, Jun 9, 2016 at 2:01 PM, Kees Cook wrote: > There has been a long-standing (and documented) issue with seccomp > where ptrace can be used to change a syscall out from under seccomp. > This is a problem for

Re: [PATCH 00/14] run seccomp after ptrace

(Oops, forgot to send this series through the lsm list...) On Thu, Jun 9, 2016 at 2:01 PM, Kees Cook wrote: > There has been a long-standing (and documented) issue with seccomp > where ptrace can be used to change a syscall out from under seccomp. > This is a problem for containers and other

Re: [RFC 01/18] capabilities: track actually used capabilities

On 06/13/16 20:32, Andy Lutomirski wrote: > On Mon, Jun 13, 2016 at 12:44 PM, Topi Miettinen wrote: >> Track what capabilities are actually used and present the current >> situation in /proc/self/status. > > What for? Excerpt from the cover letter: "There are many basic

Re: [RFC 01/18] capabilities: track actually used capabilities

On 06/13/16 20:32, Andy Lutomirski wrote: > On Mon, Jun 13, 2016 at 12:44 PM, Topi Miettinen wrote: >> Track what capabilities are actually used and present the current >> situation in /proc/self/status. > > What for? Excerpt from the cover letter: "There are many basic ways to control

Re: [PATCH] s390/oprofile: Remove deprecated create_workqueue

On 06/13/2016 12:29 PM, Robert Richter wrote: > Heiko, > > On 09.06.16 11:00:56, Heiko Carstens wrote: >> However I'm wondering if we shouldn't simply remove at least the s390 >> specific hwswampler code from the oprofile module. This would still leave >> the common code timer based sampling mode

Re: [PATCH] s390/oprofile: Remove deprecated create_workqueue

On 06/13/2016 12:29 PM, Robert Richter wrote: > Heiko, > > On 09.06.16 11:00:56, Heiko Carstens wrote: >> However I'm wondering if we shouldn't simply remove at least the s390 >> specific hwswampler code from the oprofile module. This would still leave >> the common code timer based sampling mode

[PATCH] lustre: hide call to Posix ACL in ifdef

A call to forget_cached_acl() was recently added to the lustre file system, but this is only available when CONFIG_FS_POSIX_ACL is enabled, otherwise the build now fails with: lustre/llite/file.c: In function 'll_get_acl': lustre/llite/file.c:3134:2: error: implicit declaration of function

[PATCH] lustre: hide call to Posix ACL in ifdef

A call to forget_cached_acl() was recently added to the lustre file system, but this is only available when CONFIG_FS_POSIX_ACL is enabled, otherwise the build now fails with: lustre/llite/file.c: In function 'll_get_acl': lustre/llite/file.c:3134:2: error: implicit declaration of function

Re: [PATCH] clk: rockchip: add flag CLK_SET_RATE_PARENT for dclk_vop0_div on RK3399

Hi, On Mon, Jun 13, 2016 at 11:37 AM, Brian Norris wrote: > Hi, > > On Sun, Jun 12, 2016 at 06:46:51PM +0800, Yakir Yang wrote: >> On 06/12/2016 05:48 PM, Xing Zheng wrote: >> >The functions and features VOP0 more complete than VOP1's, we need to >> >use it

Re: [PATCH] clk: rockchip: add flag CLK_SET_RATE_PARENT for dclk_vop0_div on RK3399

Hi, On Mon, Jun 13, 2016 at 11:37 AM, Brian Norris wrote: > Hi, > > On Sun, Jun 12, 2016 at 06:46:51PM +0800, Yakir Yang wrote: >> On 06/12/2016 05:48 PM, Xing Zheng wrote: >> >The functions and features VOP0 more complete than VOP1's, we need to >> >use it dclk_vop0_div operate VPLLI, and let

Re: [PATCH 2/8] kexec_file: Generalize kexec_add_buffer.

Hi Dave, Am Montag, 13 Juni 2016, 16:08:19 schrieb Thiago Jung Bauermann: > Am Montag, 13 Juni 2016, 15:29:39 schrieb Dave Young: > > On 06/12/16 at 12:10am, Thiago Jung Bauermann wrote: > > > Allow architectures to specify different memory walking functions for > > > kexec_add_buffer. Intel uses

Re: [PATCH 2/8] kexec_file: Generalize kexec_add_buffer.

Hi Dave, Am Montag, 13 Juni 2016, 16:08:19 schrieb Thiago Jung Bauermann: > Am Montag, 13 Juni 2016, 15:29:39 schrieb Dave Young: > > On 06/12/16 at 12:10am, Thiago Jung Bauermann wrote: > > > Allow architectures to specify different memory walking functions for > > > kexec_add_buffer. Intel uses

Re: [PATCH 5/6] x86/ptrace: down with test_thread_flag(TIF_IA32)

On Mon, Jun 13, 2016 at 6:50 AM, Oleg Nesterov wrote: > To avoid the confusion, let me first say that I am not going to argue > with these changes, I simply do not understand the problem space enough. > > On 06/10, Andy Lutomirski wrote: >> >> On Fri, Jun 10, 2016 at 1:07 PM,

Re: [PATCH 5/6] x86/ptrace: down with test_thread_flag(TIF_IA32)

On Mon, Jun 13, 2016 at 6:50 AM, Oleg Nesterov wrote: > To avoid the confusion, let me first say that I am not going to argue > with these changes, I simply do not understand the problem space enough. > > On 06/10, Andy Lutomirski wrote: >> >> On Fri, Jun 10, 2016 at 1:07 PM, Oleg Nesterov

[PATCH] clocksource: nps: fix nps_timer_init return value

The CLOCKSOURCE_OF_DECLARE macro ensures that the type of the init function matches the caller. In case of the new timer-nps driver, it doesn't match, so we get a warning: ../drivers/clocksource/timer-nps.c:97:208: error: comparison of distinct pointer types lacks a cast [-Werror]

Re: [RFC 05/18] limits: track and present RLIMIT_NOFILE actual max

On 06/13/2016 12:44 PM, Topi Miettinen wrote: Track maximum number of files for the process, present current maximum in /proc/self/limits. The core part should be its own patch. Also, you have this weirdly named (and racy!) function bump_rlimit. Wouldn't this be nicer if you taught the

Re: [RFC 05/18] limits: track and present RLIMIT_NOFILE actual max

On 06/13/2016 12:44 PM, Topi Miettinen wrote: Track maximum number of files for the process, present current maximum in /proc/self/limits. The core part should be its own patch. Also, you have this weirdly named (and racy!) function bump_rlimit. Wouldn't this be nicer if you taught the

[PATCH] clocksource: nps: fix nps_timer_init return value

The CLOCKSOURCE_OF_DECLARE macro ensures that the type of the init function matches the caller. In case of the new timer-nps driver, it doesn't match, so we get a warning: ../drivers/clocksource/timer-nps.c:97:208: error: comparison of distinct pointer types lacks a cast [-Werror]

[PATCH] clocksource: kona: avoid bogus warning

I could not figure out why, but gcc cannot prove that the kona_timer_init function always initializes its two outputs, and we get a warning for the use of the 'lsw' variable later, which is obviously correct. drivers/clocksource/bcm_kona_timer.c: In function 'kona_timer_init':

[PATCH] clocksource: kona: avoid bogus warning

I could not figure out why, but gcc cannot prove that the kona_timer_init function always initializes its two outputs, and we get a warning for the use of the 'lsw' variable later, which is obviously correct. drivers/clocksource/bcm_kona_timer.c: In function 'kona_timer_init':

Re: [PATCH 1/2] liblockdep: Fix compile errors

On 06/11/2016 04:36 AM, Vishal Thanki wrote: > On Sat, Jun 11, 2016 at 5:53 AM, Sasha Levin wrote: >> On 06/09/2016 09:34 AM, Vishal Thanki wrote: >>> dfaaf3fa0: (Use __jhash_mix() for iterate_chain_key()) >>> Fixed by adding jhash.h with minimal stuff required >> >> Can

Re: [PATCH 1/2] liblockdep: Fix compile errors

On 06/11/2016 04:36 AM, Vishal Thanki wrote: > On Sat, Jun 11, 2016 at 5:53 AM, Sasha Levin wrote: >> On 06/09/2016 09:34 AM, Vishal Thanki wrote: >>> dfaaf3fa0: (Use __jhash_mix() for iterate_chain_key()) >>> Fixed by adding jhash.h with minimal stuff required >> >> Can we, instead of copying it

Re: [PATCH net-next] net: ena: Add a driver for Amazon Elastic Network Adapters (ENA)

On Mon, Jun 13, 2016 at 11:46:13AM +0300, Netanel Belgazal wrote: > This is a driver for the forthcoming ENA family of networking devices. Reviewed-by: Matt Wilson > Signed-off-by: Netanel Belgazal > --- > Documentation/networking/00-INDEX

Re: [PATCH net-next] net: ena: Add a driver for Amazon Elastic Network Adapters (ENA)

On Mon, Jun 13, 2016 at 11:46:13AM +0300, Netanel Belgazal wrote: > This is a driver for the forthcoming ENA family of networking devices. Reviewed-by: Matt Wilson > Signed-off-by: Netanel Belgazal > --- > Documentation/networking/00-INDEX |2 + >

Re: [RFC 01/18] capabilities: track actually used capabilities

On Mon, Jun 13, 2016 at 12:44 PM, Topi Miettinen wrote: > Track what capabilities are actually used and present the current > situation in /proc/self/status. What for? What is the intended behavior on fork()? Whatever the intended behavior is, there should IMO be a selftest

Re: [PATCH v2 4/4] dynamic_debug: add jump label support

On 06/13/2016 04:23 PM, Arnd Bergmann wrote: > On Monday, June 13, 2016 6:05:22 PM CEST Arnd Bergmann wrote: >> On Friday, June 10, 2016 11:33:07 AM CEST Jason Baron wrote: >>> On 06/10/2016 05:54 AM, Arnd Bergmann wrote: On Friday, May 20, 2016 5:16:36 PM CEST Jason Baron wrote: >

Re: [RFC 01/18] capabilities: track actually used capabilities

On Mon, Jun 13, 2016 at 12:44 PM, Topi Miettinen wrote: > Track what capabilities are actually used and present the current > situation in /proc/self/status. What for? What is the intended behavior on fork()? Whatever the intended behavior is, there should IMO be a selftest for it. --Andy

Re: [PATCH v2 4/4] dynamic_debug: add jump label support

On 06/13/2016 04:23 PM, Arnd Bergmann wrote: > On Monday, June 13, 2016 6:05:22 PM CEST Arnd Bergmann wrote: >> On Friday, June 10, 2016 11:33:07 AM CEST Jason Baron wrote: >>> On 06/10/2016 05:54 AM, Arnd Bergmann wrote: On Friday, May 20, 2016 5:16:36 PM CEST Jason Baron wrote: >

Re: 4.7-rc3: Reported regressions from 4.7

On Monday, June 13, 2016 03:53:35 PM Borislav Petkov wrote: > On Mon, Jun 13, 2016 at 03:53:20PM +0200, Rafael J. Wysocki wrote: > > I used kernel BZ entries for two reasons. > > > > First, some of the bugs were in the kernel BZ already, so they could be > > added > > to the tracked list very

Re: [PATCH v2 1/7] mm/compaction: split freepages without holding the zone lock

On 05/25/2016 10:37 PM, js1...@gmail.com wrote: > From: Joonsoo Kim > > We don't need to split freepages with holding the zone lock. It will cause > more contention on zone lock so not desirable. > > Signed-off-by: Joonsoo Kim Hey Joonsoo, I'm

Re: 4.7-rc3: Reported regressions from 4.7

On Monday, June 13, 2016 03:53:35 PM Borislav Petkov wrote: > On Mon, Jun 13, 2016 at 03:53:20PM +0200, Rafael J. Wysocki wrote: > > I used kernel BZ entries for two reasons. > > > > First, some of the bugs were in the kernel BZ already, so they could be > > added > > to the tracked list very

Re: [PATCH v2 1/7] mm/compaction: split freepages without holding the zone lock

On 05/25/2016 10:37 PM, js1...@gmail.com wrote: > From: Joonsoo Kim > > We don't need to split freepages with holding the zone lock. It will cause > more contention on zone lock so not desirable. > > Signed-off-by: Joonsoo Kim Hey Joonsoo, I'm seeing the following corruption/crash which

Re: [PATCH] ARM: mm: fix location of _etext

On Wed, Jun 8, 2016 at 4:11 PM, Kees Cook wrote: > The _etext position is defined to be the end of the kernel text code, > and should not include any part of the data segments. This interferes > with things that might check memory ranges and expect executable code > up to

Re: [PATCH] ARM: mm: fix location of _etext

On Wed, Jun 8, 2016 at 4:11 PM, Kees Cook wrote: > The _etext position is defined to be the end of the kernel text code, > and should not include any part of the data segments. This interferes > with things that might check memory ranges and expect executable code > up to _etext. > >

Re: [PATCH v2 4/4] dynamic_debug: add jump label support

On Monday, June 13, 2016 6:05:22 PM CEST Arnd Bergmann wrote: > On Friday, June 10, 2016 11:33:07 AM CEST Jason Baron wrote: > > On 06/10/2016 05:54 AM, Arnd Bergmann wrote: > > > On Friday, May 20, 2016 5:16:36 PM CEST Jason Baron wrote: > > >> Although dynamic debug is often only used for debug

Re: [PATCH v2 4/4] dynamic_debug: add jump label support

On Monday, June 13, 2016 6:05:22 PM CEST Arnd Bergmann wrote: > On Friday, June 10, 2016 11:33:07 AM CEST Jason Baron wrote: > > On 06/10/2016 05:54 AM, Arnd Bergmann wrote: > > > On Friday, May 20, 2016 5:16:36 PM CEST Jason Baron wrote: > > >> Although dynamic debug is often only used for debug

[PATCH] x86/SVM: Fix implicit declaration issue for __default_cpu_present_to_apicid()

The commit 8221c1370056 ("svm: Manage vcpu load/unload when enable AVIC") introduces a build error due to implicit function declaration with#ifdef CONFIG_X86_32 and #ifndef CONFIG_X86_LOCAL_APIC. with Kbuild test robot config file (i386-randconfig-x0-06121009). This patch fixes the issue by using

[PATCH] x86/SVM: Fix implicit declaration issue for __default_cpu_present_to_apicid()

The commit 8221c1370056 ("svm: Manage vcpu load/unload when enable AVIC") introduces a build error due to implicit function declaration with#ifdef CONFIG_X86_32 and #ifndef CONFIG_X86_LOCAL_APIC. with Kbuild test robot config file (i386-randconfig-x0-06121009). This patch fixes the issue by using

Re: [PATCH] brcmfmac: rework function picking free BSS index

On 13 June 2016 at 21:30, Arend van Spriel wrote: > On 09-06-16 21:16, Arend van Spriel wrote: >> On 26-05-16 01:44, Rafał Miłecki wrote: >>> The old implementation was overcomplicated and slightly bugged in some >>> corner cases. >>> > > [...] > >>> New code is

Re: [PATCH] brcmfmac: rework function picking free BSS index

On 13 June 2016 at 21:30, Arend van Spriel wrote: > On 09-06-16 21:16, Arend van Spriel wrote: >> On 26-05-16 01:44, Rafał Miłecki wrote: >>> The old implementation was overcomplicated and slightly bugged in some >>> corner cases. >>> > > [...] > >>> New code is simpler, placed in file where it's

[PATCH v1 1/1] x86/platform/intel-mid: Add Power Management Unit driver

Add Power Management Unit driver to handle power states of South Complex devices on Intel Tangier. In the future it might be expanded to cover North Complex devices as well. With this driver the power state of the host controllers such as SPI, I2C, UART, eMMC, and DMA would be managed.

[PATCH v1 1/1] x86/platform/intel-mid: Add Power Management Unit driver

Add Power Management Unit driver to handle power states of South Complex devices on Intel Tangier. In the future it might be expanded to cover North Complex devices as well. With this driver the power state of the host controllers such as SPI, I2C, UART, eMMC, and DMA would be managed.

Re: [PATCH] gcc-plugins: disable under COMPILE_TEST

On Mon, Jun 13, 2016 at 1:40 AM, Sedat Dilek wrote: > On Sat, Jun 11, 2016 at 6:12 PM, Kees Cook wrote: >> Since adding the gcc plugin development headers is required for the >> gcc plugin support, we should ease into this new kernel build dependency

Re: [PATCH] gcc-plugins: disable under COMPILE_TEST

On Mon, Jun 13, 2016 at 1:40 AM, Sedat Dilek wrote: > On Sat, Jun 11, 2016 at 6:12 PM, Kees Cook wrote: >> Since adding the gcc plugin development headers is required for the >> gcc plugin support, we should ease into this new kernel build dependency >> more slowly. For now, disable the gcc

Re: [PATCH 4/8] ntb_perf: Wait for link before running test

On Fri, 2016-06-10 at 16:54 -0600, Logan Gunthorpe wrote: > Instead of returning immediately with an error when the link is > down, wait for the link to come up (or the user sends a SIGINT). > > This is to make scripting ntb_perf easier. > > Signed-off-by: Logan Gunthorpe

Re: [PATCH 4/8] ntb_perf: Wait for link before running test

On Fri, 2016-06-10 at 16:54 -0600, Logan Gunthorpe wrote: > Instead of returning immediately with an error when the link is > down, wait for the link to come up (or the user sends a SIGINT). > > This is to make scripting ntb_perf easier. > > Signed-off-by: Logan Gunthorpe Acked-by: Dave Jiang

Re: [PATCH] gcc-plugins: disable under COMPILE_TEST

On Mon, Jun 13, 2016 at 11:32 AM, Austin S. Hemmelgarn wrote: > On 2016-06-12 20:18, Emese Revfy wrote: >> >> On Sun, 12 Jun 2016 15:25:39 -0700 >> Kees Cook wrote: >> >>> I don't like this because it means if someone specifically selects >>> some

Re: [PATCH] gcc-plugins: disable under COMPILE_TEST

On Mon, Jun 13, 2016 at 11:32 AM, Austin S. Hemmelgarn wrote: > On 2016-06-12 20:18, Emese Revfy wrote: >> >> On Sun, 12 Jun 2016 15:25:39 -0700 >> Kees Cook wrote: >> >>> I don't like this because it means if someone specifically selects >>> some plugins in their .config, and the headers are

Re: [PATCH 3/8] ntb_perf: Return results by reading the run file

On Fri, 2016-06-10 at 16:54 -0600, Logan Gunthorpe wrote: > Instead of having to watch logs, allow the results to be retrieved > by reading back the run file. This file will return "running" when > the test is running and nothing if no tests have been run yet. > It returns 1 line per thread, and

Re: [PATCH 3/8] ntb_perf: Return results by reading the run file

On Fri, 2016-06-10 at 16:54 -0600, Logan Gunthorpe wrote: > Instead of having to watch logs, allow the results to be retrieved > by reading back the run file. This file will return "running" when > the test is running and nothing if no tests have been run yet. > It returns 1 line per thread, and

Re: [PATCH -next] mtd: nand: sunxi: fix return value check in sunxi_nfc_dma_op_prepare()

On Mon, 13 Jun 2016 14:27:18 + weiyj...@163.com wrote: > From: Wei Yongjun > > In case of error, the function dmaengine_prep_slave_sg() returns NULL > pointer not ERR_PTR(). The IS_ERR() test in the return value check > should be replaced with NULL test. > >

Re: [PATCH -next] mtd: nand: sunxi: fix return value check in sunxi_nfc_dma_op_prepare()

On Mon, 13 Jun 2016 14:27:18 + weiyj...@163.com wrote: > From: Wei Yongjun > > In case of error, the function dmaengine_prep_slave_sg() returns NULL > pointer not ERR_PTR(). The IS_ERR() test in the return value check > should be replaced with NULL test. > > Signed-off-by: Wei Yongjun

Re: [PATCH V9 09/11] ARM64/PCI: ACPI support for legacy IRQs parsing and consolidation with DT code

On Mon, Jun 13, 2016 at 3:40 AM, Lorenzo Pieralisi wrote: > > On Fri, Jun 10, 2016 at 06:36:12PM -0500, Bjorn Helgaas wrote: > > On Fri, Jun 10, 2016 at 09:55:17PM +0200, Tomasz Nowicki wrote: > > > To enable PCI legacy IRQs on platforms booting with ACPI, arch code > >

Re: [PATCH V9 09/11] ARM64/PCI: ACPI support for legacy IRQs parsing and consolidation with DT code

On Mon, Jun 13, 2016 at 3:40 AM, Lorenzo Pieralisi wrote: > > On Fri, Jun 10, 2016 at 06:36:12PM -0500, Bjorn Helgaas wrote: > > On Fri, Jun 10, 2016 at 09:55:17PM +0200, Tomasz Nowicki wrote: > > > To enable PCI legacy IRQs on platforms booting with ACPI, arch code > > > should include ACPI

Re: [RESEND PATCH 1/3] rfkill: Create "rfkill-airplane-mode" LED trigger

On 13 June 2016 at 15:00, Pavel Machek wrote: > Hi! > >> > João, that means you should send a patch to add the ::rfkill suffix. >> > >> >> IMO "airplane" (or maybe "airplane-mode") is a better suffix, as it >> reflects the label on the machine's chassis. I'll name it >>

Re: [RESEND PATCH 1/3] rfkill: Create "rfkill-airplane-mode" LED trigger

On 13 June 2016 at 15:00, Pavel Machek wrote: > Hi! > >> > João, that means you should send a patch to add the ::rfkill suffix. >> > >> >> IMO "airplane" (or maybe "airplane-mode") is a better suffix, as it >> reflects the label on the machine's chassis. I'll name it >> "asus-wireless::airplane"

Re: [PATCH v3 03/13] spi: sun4i: fix FIFO limit

On Mon, Jun 13, 2016 at 05:46:49PM -, Michal Suchanek wrote: > When testing SPI without DMA I noticed that filling the FIFO on the > spi controller causes timeout. > > Always leave room for one byte in the FIFO. > > Signed-off-by: Michal Suchanek Acked-by: Maxime Ripard

Re: [PATCH v3 04/13] spi: sunxi: expose maximum transfer size limit

On Mon, Jun 13, 2016 at 05:46:50PM -, Michal Suchanek wrote: > The sun4i spi hardware can trasfer at most 63 bytes of data without DMA > support so report the limitation. Same for sun6i. > > Signed-off-by: Michal Suchanek Acked-by: Maxime Ripard

Re: [PATCH v3 03/13] spi: sun4i: fix FIFO limit

On Mon, Jun 13, 2016 at 05:46:49PM -, Michal Suchanek wrote: > When testing SPI without DMA I noticed that filling the FIFO on the > spi controller causes timeout. > > Always leave room for one byte in the FIFO. > > Signed-off-by: Michal Suchanek Acked-by: Maxime Ripard Thanks, Maxime

Re: [PATCH v3 04/13] spi: sunxi: expose maximum transfer size limit

On Mon, Jun 13, 2016 at 05:46:50PM -, Michal Suchanek wrote: > The sun4i spi hardware can trasfer at most 63 bytes of data without DMA > support so report the limitation. Same for sun6i. > > Signed-off-by: Michal Suchanek Acked-by: Maxime Ripard Maxime -- Maxime Ripard, Free Electrons

Re: [PATCH v3 00/13] sunxi spi fixes

On Mon, Jun 13, 2016 at 05:46:48PM -, Michal Suchanek wrote: > Hello, > > This is update of the sunxi spi patches that should give full-featured SPI > driver. > > First three patches fix issues with the current driver and can be of use for > stable kernels so adding cc for those. > > I

Re: [PATCH v3 00/13] sunxi spi fixes

On Mon, Jun 13, 2016 at 05:46:48PM -, Michal Suchanek wrote: > Hello, > > This is update of the sunxi spi patches that should give full-featured SPI > driver. > > First three patches fix issues with the current driver and can be of use for > stable kernels so adding cc for those. > > I

Re: [PATCH v3 02/13] spi: sunxi: fix transfer timeout

On Mon, Jun 13, 2016 at 05:46:49PM -, Michal Suchanek wrote: > The trasfer timeout is fixed at 1000 ms. Reading a 4Mbyte flash over > 1MHz SPI bus takes way longer than that. Calculate the timeout from the > actual time the transfer is supposed to take and multiply by 2 for good > measure. >

Re: [PATCH v3 02/13] spi: sunxi: fix transfer timeout

On Mon, Jun 13, 2016 at 05:46:49PM -, Michal Suchanek wrote: > The trasfer timeout is fixed at 1000 ms. Reading a 4Mbyte flash over > 1MHz SPI bus takes way longer than that. Calculate the timeout from the > actual time the transfer is supposed to take and multiply by 2 for good > measure. >

Re: [PATCH v3 01/13] spi: sunxi: set maximum and minimum speed of SPI master

On Mon, Jun 13, 2016 at 05:46:49PM -, Michal Suchanek wrote: > The speed limits are unset in the sun4i and sun6i SPI drivers. > > The maximum speed of SPI master is used when maximum speed of SPI slave > is not specified. Also the __spi_validate function should check that > transfer speeds do

Re: [PATCH v3 01/13] spi: sunxi: set maximum and minimum speed of SPI master

On Mon, Jun 13, 2016 at 05:46:49PM -, Michal Suchanek wrote: > The speed limits are unset in the sun4i and sun6i SPI drivers. > > The maximum speed of SPI master is used when maximum speed of SPI slave > is not specified. Also the __spi_validate function should check that > transfer speeds do

Re: [very-RFC 0/8] TSN driver for the kernel

On Mon, Jun 13, 2016 at 01:47:13PM +0200, Richard Cochran wrote: > 3. ALSA support for tunable AD/DA clocks. The rate of the Listener's >DA clock must match that of the Talker and the other Listeners. >Either you adjust it in HW using a VCO or similar, or you do >adaptive sample rate

Re: [very-RFC 0/8] TSN driver for the kernel

On Mon, Jun 13, 2016 at 01:47:13PM +0200, Richard Cochran wrote: > 3. ALSA support for tunable AD/DA clocks. The rate of the Listener's >DA clock must match that of the Talker and the other Listeners. >Either you adjust it in HW using a VCO or similar, or you do >adaptive sample rate

[ANNOUNCE] Git v2.9.0

The latest feature release Git v2.9.0 is now available at the usual places. It is comprised of 497 non-merge commits since v2.8.0, contributed by 75 people, 28 of which are new faces. The tarballs are found at: https://www.kernel.org/pub/software/scm/git/ The following public repositories

[ANNOUNCE] Git v2.9.0

The latest feature release Git v2.9.0 is now available at the usual places. It is comprised of 497 non-merge commits since v2.8.0, contributed by 75 people, 28 of which are new faces. The tarballs are found at: https://www.kernel.org/pub/software/scm/git/ The following public repositories

Re: [PATCH] locking/qspinlock: Use atomic_sub_return_release in queued_spin_unlock

On Fri, 03 Jun 2016, Pan Xinhui wrote: The existing version uses a heavy barrier while only release semantics is required. So use atomic_sub_return_release instead. Suggested-by: Peter Zijlstra (Intel) Signed-off-by: Pan Xinhui I just

Re: [PATCH] locking/qspinlock: Use atomic_sub_return_release in queued_spin_unlock

On Fri, 03 Jun 2016, Pan Xinhui wrote: The existing version uses a heavy barrier while only release semantics is required. So use atomic_sub_return_release instead. Suggested-by: Peter Zijlstra (Intel) Signed-off-by: Pan Xinhui I just noticed this change in -tip and, while I know that

[RFC 17/18] limits: track RLIMIT_RTPRIO actual max

Track maximum RT priority, presented in /proc/self/limits. Signed-off-by: Topi Miettinen --- kernel/sched/core.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/kernel/sched/core.c b/kernel/sched/core.c index 817d720..d31a06a 100644 --- a/kernel/sched/core.c +++

[RFC 17/18] limits: track RLIMIT_RTPRIO actual max

Track maximum RT priority, presented in /proc/self/limits. Signed-off-by: Topi Miettinen --- kernel/sched/core.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/kernel/sched/core.c b/kernel/sched/core.c index 817d720..d31a06a 100644 --- a/kernel/sched/core.c +++ b/kernel/sched/core.c @@

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