Re: [PATCH v5 1/4] leds: core: add generic support for RGB Color LED's

On 04/01/2016 03:57 PM, Pavel Machek wrote: Hi! On Wed 2016-03-30 09:57:38, Jacek Anaszewski wrote: Hi Heiner and Pavel, On 03/29/2016 10:38 PM, Heiner Kallweit wrote: Am 29.03.2016 um 12:02 schrieb Pavel Machek: Hi! First, please Cc me on RGB color support. Add generic support for RGB

Re: [PATCH v5 1/4] leds: core: add generic support for RGB Color LED's

On 04/01/2016 03:57 PM, Pavel Machek wrote: Hi! On Wed 2016-03-30 09:57:38, Jacek Anaszewski wrote: Hi Heiner and Pavel, On 03/29/2016 10:38 PM, Heiner Kallweit wrote: Am 29.03.2016 um 12:02 schrieb Pavel Machek: Hi! First, please Cc me on RGB color support. Add generic support for RGB

Re: [lustre-devel] [RFC PATCH 0/3] staging: lustre: detypedef

On Fri, 2016-04-01 at 15:58 +, Simmons, James A. wrote: > > When would be an appropriate time to submit patches similar to > > below that individually remove various typedefs from lustre code? > > > > These are pretty trivial to produce and verify so there's no > > particular hurry to do them

Re: [lustre-devel] [RFC PATCH 0/3] staging: lustre: detypedef

On Fri, 2016-04-01 at 15:58 +, Simmons, James A. wrote: > > When would be an appropriate time to submit patches similar to > > below that individually remove various typedefs from lustre code? > > > > These are pretty trivial to produce and verify so there's no > > particular hurry to do them

[PATCH 4/6] drivers/gpio: make gpio-palmas.c explicitly non-modular

The Kconfig currently controlling compilation of this code is: drivers/gpio/Kconfig:config GPIO_PALMAS drivers/gpio/Kconfig: bool "TI PALMAS series PMICs GPIO" ...meaning that it currently is not being built as a module by anyone. Lets remove the modular code that is essentially orphaned, so

[PATCH 4/6] drivers/gpio: make gpio-palmas.c explicitly non-modular

The Kconfig currently controlling compilation of this code is: drivers/gpio/Kconfig:config GPIO_PALMAS drivers/gpio/Kconfig: bool "TI PALMAS series PMICs GPIO" ...meaning that it currently is not being built as a module by anyone. Lets remove the modular code that is essentially orphaned, so

[PATCH 5/6] drivers/gpio: make gpio-tps65910.c explicitly non-modular

The Kconfig currently controlling compilation of this code is: drivers/gpio/Kconfig:config GPIO_TPS65910 drivers/gpio/Kconfig: bool "TPS65910 GPIO" ...meaning that it currently is not being built as a module by anyone. Lets remove the modular code that is essentially orphaned, so that when

[PATCH 5/6] drivers/gpio: make gpio-tps65910.c explicitly non-modular

The Kconfig currently controlling compilation of this code is: drivers/gpio/Kconfig:config GPIO_TPS65910 drivers/gpio/Kconfig: bool "TPS65910 GPIO" ...meaning that it currently is not being built as a module by anyone. Lets remove the modular code that is essentially orphaned, so that when

[PATCH 3/6] drivers/gpio: make gpio-sx150x.c explicitly non-modular

The Kconfig currently controlling compilation of this code is: drivers/gpio/Kconfig:config GPIO_SX150X drivers/gpio/Kconfig: bool "Semtech SX150x I2C GPIO expander" ...meaning that it currently is not being built as a module by anyone. Lets remove the modular code that is essentially

[PATCH 3/6] drivers/gpio: make gpio-sx150x.c explicitly non-modular

The Kconfig currently controlling compilation of this code is: drivers/gpio/Kconfig:config GPIO_SX150X drivers/gpio/Kconfig: bool "Semtech SX150x I2C GPIO expander" ...meaning that it currently is not being built as a module by anyone. Lets remove the modular code that is essentially

[PATCH 1/6] drivers/gpio: make gpio-rc5t583.c explicitly non-modular

The Kconfig currently controlling compilation of this code is: drivers/gpio/Kconfig:config GPIO_RC5T583 drivers/gpio/Kconfig: bool "RICOH RC5T583 GPIO" ...meaning that it currently is not being built as a module by anyone. Lets remove the modular code that is essentially orphaned, so that

[PATCH 0/6] gpio: batch #2: remove modular code from non-modular drivers

For GPIO, I've divided up the the audit of modular usage in non-modular drivers into three categories to ease review and limit the batch size. Group #1 has been submitted and merged ; this group here is group #2. The breakdown of the three groups is as follows: 1) just replacement of modular

[PATCH 6/6] drivers/gpio: make gpio-tps6586x.c explicitly non-modular

The Kconfig currently controlling compilation of this code is: drivers/gpio/Kconfig:config GPIO_TPS6586X drivers/gpio/Kconfig: bool "TPS6586X GPIO" ...meaning that it currently is not being built as a module by anyone. Lets remove the modular code that is essentially orphaned, so that when

[PATCH 2/6] drivers/gpio: make gpio-tc3589x.c explicitly non-modular

The Kconfig currently controlling compilation of this code is: drivers/gpio/Kconfig:config GPIO_TC3589X drivers/gpio/Kconfig: bool "TC3589X GPIOs" ...meaning that it currently is not being built as a module by anyone. Lets remove the modular code that is essentially orphaned, so that when

[PATCH 1/6] drivers/gpio: make gpio-rc5t583.c explicitly non-modular

The Kconfig currently controlling compilation of this code is: drivers/gpio/Kconfig:config GPIO_RC5T583 drivers/gpio/Kconfig: bool "RICOH RC5T583 GPIO" ...meaning that it currently is not being built as a module by anyone. Lets remove the modular code that is essentially orphaned, so that

[PATCH 0/6] gpio: batch #2: remove modular code from non-modular drivers

For GPIO, I've divided up the the audit of modular usage in non-modular drivers into three categories to ease review and limit the batch size. Group #1 has been submitted and merged ; this group here is group #2. The breakdown of the three groups is as follows: 1) just replacement of modular

[PATCH 6/6] drivers/gpio: make gpio-tps6586x.c explicitly non-modular

The Kconfig currently controlling compilation of this code is: drivers/gpio/Kconfig:config GPIO_TPS6586X drivers/gpio/Kconfig: bool "TPS6586X GPIO" ...meaning that it currently is not being built as a module by anyone. Lets remove the modular code that is essentially orphaned, so that when

[PATCH 2/6] drivers/gpio: make gpio-tc3589x.c explicitly non-modular

The Kconfig currently controlling compilation of this code is: drivers/gpio/Kconfig:config GPIO_TC3589X drivers/gpio/Kconfig: bool "TC3589X GPIOs" ...meaning that it currently is not being built as a module by anyone. Lets remove the modular code that is essentially orphaned, so that when

Re: [PATCH v2] ARM: dts: dra7: Correct clock tree for sys_32k_ck

On 04/01/2016 06:36 PM, Tony Lindgren wrote: Hi, * Tony Lindgren [160331 10:04]: * Keerthy [160331 02:26]: On Thursday 31 March 2016 12:00 PM, Tero Kristo wrote: On 03/31/2016 12:32 AM, Tony Lindgren wrote: * Tony Lindgren [160330

Re: [PATCH v2] ARM: dts: dra7: Correct clock tree for sys_32k_ck

On 04/01/2016 06:36 PM, Tony Lindgren wrote: Hi, * Tony Lindgren [160331 10:04]: * Keerthy [160331 02:26]: On Thursday 31 March 2016 12:00 PM, Tero Kristo wrote: On 03/31/2016 12:32 AM, Tony Lindgren wrote: * Tony Lindgren [160330 14:19]: * Keerthy [160314 05:04]: This is w.r.t

[PATCH RESEND 1/2] coredump: get rid of coredump_params->written

From: Omar Sandoval cprm->written is redundant with cprm->file->f_pos, so use that instead. --- arch/powerpc/platforms/cell/spufs/coredump.c | 5 +++-- fs/binfmt_elf.c | 2 +- fs/binfmt_elf_fdpic.c| 2 +- fs/coredump.c

[PATCH RESEND 1/2] coredump: get rid of coredump_params->written

From: Omar Sandoval cprm->written is redundant with cprm->file->f_pos, so use that instead. --- arch/powerpc/platforms/cell/spufs/coredump.c | 5 +++-- fs/binfmt_elf.c | 2 +- fs/binfmt_elf_fdpic.c| 2 +- fs/coredump.c

[PATCH RESEND 0/2] fix RLIMIT_CORE accounting for sparse dumps

From: Omar Sandoval Resending this since it didn't get in -rc1. Rebased on Linus' current tree. Please apply. Original cover letter below: Hi, Someone here reported that they were getting truncated core dumps even when RLIMIT_CORE was larger than the physical memory of the

[PATCH RESEND 0/2] fix RLIMIT_CORE accounting for sparse dumps

From: Omar Sandoval Resending this since it didn't get in -rc1. Rebased on Linus' current tree. Please apply. Original cover letter below: Hi, Someone here reported that they were getting truncated core dumps even when RLIMIT_CORE was larger than the physical memory of the machine. It looks

[PATCH RESEND 2/2] coredump: only charge written data against RLIMIT_CORE

From: Omar Sandoval Commit 9b56d54380ad ("dump_skip(): dump_seek() replacement taking coredump_params") introduced a regression with regard to RLIMIT_CORE. Previously, when a core dump was sparse, only the data that was actually written out would count against the limit. Now, the

[PATCH RESEND 2/2] coredump: only charge written data against RLIMIT_CORE

From: Omar Sandoval Commit 9b56d54380ad ("dump_skip(): dump_seek() replacement taking coredump_params") introduced a regression with regard to RLIMIT_CORE. Previously, when a core dump was sparse, only the data that was actually written out would count against the limit. Now, the sparse ranges

Re: [lustre-devel] [RFC PATCH 0/3] staging: lustre: detypedef

On Fri, 2016-04-01 at 14:23 +, Drokin, Oleg wrote: > On Apr 1, 2016, at 9:02 AM, Joe Perches wrote: > > > > Question about removing lustre typedefs. > > > > Various bits of lustre code use a mix of struct foo and foo_t. > > > > When would be an appropriate time to submit patches similar to

Re: [lustre-devel] [RFC PATCH 0/3] staging: lustre: detypedef

On Fri, 2016-04-01 at 14:23 +, Drokin, Oleg wrote: > On Apr 1, 2016, at 9:02 AM, Joe Perches wrote: > > > > Question about removing lustre typedefs. > > > > Various bits of lustre code use a mix of struct foo and foo_t. > > > > When would be an appropriate time to submit patches similar to

Re: [PATCH] net: mvneta: use cache_line_size() to get cacheline size

From: Jisheng Zhang Date: Fri, 1 Apr 2016 17:12:49 +0800 > L1_CACHE_BYTES may not be the real cacheline size, use cache_line_size > to determine the cacheline size in runtime. > > Signed-off-by: Jisheng Zhang > Suggested-by: Marcin Wojtas

Re: [PATCH] net: mvneta: use cache_line_size() to get cacheline size

From: Jisheng Zhang Date: Fri, 1 Apr 2016 17:12:49 +0800 > L1_CACHE_BYTES may not be the real cacheline size, use cache_line_size > to determine the cacheline size in runtime. > > Signed-off-by: Jisheng Zhang > Suggested-by: Marcin Wojtas Applied.

Re: [PATCH] net: mvpp2: use cache_line_size() to get cacheline size

From: Jisheng Zhang Date: Fri, 1 Apr 2016 17:11:05 +0800 > L1_CACHE_BYTES may not be the real cacheline size, use cache_line_size > to determine the cacheline size in runtime. > > Signed-off-by: Jisheng Zhang > Suggested-by: Marcin Wojtas

Re: [PATCH] net: mvpp2: use cache_line_size() to get cacheline size

From: Jisheng Zhang Date: Fri, 1 Apr 2016 17:11:05 +0800 > L1_CACHE_BYTES may not be the real cacheline size, use cache_line_size > to determine the cacheline size in runtime. > > Signed-off-by: Jisheng Zhang > Suggested-by: Marcin Wojtas Applied.

Re: [PATCH v3 2/2] mmc: dw_mmc: add resets support to dw_mmc

Am Mittwoch, 30. März 2016, 15:24:56 schrieb Guodong Xu: [...] > @@ -2949,7 +2956,9 @@ int dw_mci_probe(struct dw_mci *host) > > if (!host->pdata) { > host->pdata = dw_mci_parse_dt(host); > - if (IS_ERR(host->pdata)) { > + if (PTR_ERR(host->pdata) ==

Re: [PATCH v3 2/2] mmc: dw_mmc: add resets support to dw_mmc

Am Mittwoch, 30. März 2016, 15:24:56 schrieb Guodong Xu: [...] > @@ -2949,7 +2956,9 @@ int dw_mci_probe(struct dw_mci *host) > > if (!host->pdata) { > host->pdata = dw_mci_parse_dt(host); > - if (IS_ERR(host->pdata)) { > + if (PTR_ERR(host->pdata) ==

Re: [PATCH v3 2/2] mmc: dw_mmc: add resets support to dw_mmc

Am Mittwoch, 30. März 2016, 20:40:31 schrieb Jaehoon Chung: > modified Rob's mail address. > > On 03/30/2016 04:24 PM, Guodong Xu wrote: > > mmc registers may in abnormal state if mmc is used in bootloader, > > eg. to support booting from eMMC. So we need reset mmc registers > > when kernel boots

Re: [PATCH v3 2/2] mmc: dw_mmc: add resets support to dw_mmc

Am Mittwoch, 30. März 2016, 20:40:31 schrieb Jaehoon Chung: > modified Rob's mail address. > > On 03/30/2016 04:24 PM, Guodong Xu wrote: > > mmc registers may in abnormal state if mmc is used in bootloader, > > eg. to support booting from eMMC. So we need reset mmc registers > > when kernel boots

Re: [intel-pstate driver regression] processor frequency very high even if in idle

On Fri, 2016-04-01 at 11:31 -0700, Doug Smythies wrote: > On 2106.034.01 10:45 Srinivas Pandruvada wrote: > > > > On Fri, 2016-04-01 at 16:06 +0200, Jörg Otte wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Done. Attached the tracer. > > > For me it looks like

Re: [intel-pstate driver regression] processor frequency very high even if in idle

On Fri, 2016-04-01 at 11:31 -0700, Doug Smythies wrote: > On 2106.034.01 10:45 Srinivas Pandruvada wrote: > > > > On Fri, 2016-04-01 at 16:06 +0200, Jörg Otte wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Done. Attached the tracer. > > > For me it looks like

Re: [PATCH (net.git) 0/3] stmmac MDIO and normal descr fixes

From: Giuseppe Cavallaro Date: Fri, 1 Apr 2016 09:07:13 +0200 > This patch series is to fix the problems below and recently debugged > in this mailing list: > > o to fix a problem for the HW where the normal descriptor > o to fix the mdio registration according to the

Re: [PATCH v2] iov_iter: Fix out-of-bound access in iov_iter_advance()

On Fri, 01 Apr 2016 19:39:20 +0200, Al Viro wrote: > > On Fri, Apr 01, 2016 at 05:02:04PM +0200, Takashi Iwai wrote: > > Currently, iov_iter_advance() just calls iterate_and_advance() macro > > as is, even if size=0 is passed. Usually it is OK to pass size=0 to > > the macro. However, when the

Re: [PATCH (net.git) 0/3] stmmac MDIO and normal descr fixes

From: Giuseppe Cavallaro Date: Fri, 1 Apr 2016 09:07:13 +0200 > This patch series is to fix the problems below and recently debugged > in this mailing list: > > o to fix a problem for the HW where the normal descriptor > o to fix the mdio registration according to the different > platform

Re: [PATCH v2] iov_iter: Fix out-of-bound access in iov_iter_advance()

On Fri, 01 Apr 2016 19:39:20 +0200, Al Viro wrote: > > On Fri, Apr 01, 2016 at 05:02:04PM +0200, Takashi Iwai wrote: > > Currently, iov_iter_advance() just calls iterate_and_advance() macro > > as is, even if size=0 is passed. Usually it is OK to pass size=0 to > > the macro. However, when the

Re: [PATCH] net: mvpp2: fix maybe-uninitialized warning

From: Jisheng Zhang Date: Thu, 31 Mar 2016 17:01:23 +0800 > This is to fix the following maybe-uninitialized warning: > > drivers/net/ethernet/marvell/mvpp2.c:6007:18: warning: 'err' may be > used uninitialized in this function [-Wmaybe-uninitialized] > > Signed-off-by:

Re: [PATCH] net: mvpp2: fix maybe-uninitialized warning

From: Jisheng Zhang Date: Thu, 31 Mar 2016 17:01:23 +0800 > This is to fix the following maybe-uninitialized warning: > > drivers/net/ethernet/marvell/mvpp2.c:6007:18: warning: 'err' may be > used uninitialized in this function [-Wmaybe-uninitialized] > > Signed-off-by: Jisheng Zhang

Re: [RFC PATCH 6/6] ppc: ebpf/jit: Implement JIT compiler for extended BPF

On 04/01/2016 08:10 PM, Alexei Starovoitov wrote: On 4/1/16 2:58 AM, Naveen N. Rao wrote: PPC64 eBPF JIT compiler. Works for both ABIv1 and ABIv2. Enable with: echo 1 > /proc/sys/net/core/bpf_jit_enable or echo 2 > /proc/sys/net/core/bpf_jit_enable ... to see the generated JIT code. This can

Re: [RFC PATCH 6/6] ppc: ebpf/jit: Implement JIT compiler for extended BPF

On 04/01/2016 08:10 PM, Alexei Starovoitov wrote: On 4/1/16 2:58 AM, Naveen N. Rao wrote: PPC64 eBPF JIT compiler. Works for both ABIv1 and ABIv2. Enable with: echo 1 > /proc/sys/net/core/bpf_jit_enable or echo 2 > /proc/sys/net/core/bpf_jit_enable ... to see the generated JIT code. This can

Re: [PATCH 4/7] ARM: dts: Enable N950 keyboard sleep leds by default

* Pavel Machek [160401 05:46]: > Hi! > > > > On Tue, Mar 29, 2016 at 12:51:28PM +0200, Pavel Machek wrote: > > > > For 1-3 in the series, Acked-by: Pavel Machek > > > > > > > > > Like the Nokia N900, the N950 has leds to show > > > > > the state of sys_clkreq and

Re: [PATCH 4/7] ARM: dts: Enable N950 keyboard sleep leds by default

* Pavel Machek [160401 05:46]: > Hi! > > > > On Tue, Mar 29, 2016 at 12:51:28PM +0200, Pavel Machek wrote: > > > > For 1-3 in the series, Acked-by: Pavel Machek > > > > > > > > > Like the Nokia N900, the N950 has leds to show > > > > > the state of sys_clkreq and sys_off_mode pins. > > > > >

RE: [intel-pstate driver regression] processor frequency very high even if in idle

On 2106.034.01 10:45 Srinivas Pandruvada wrote: > On Fri, 2016-04-01 at 16:06 +0200, Jörg Otte wrote: > > > > > > >> Done. Attached the tracer. >> For me it looks like the previous one of the failing case. > > The traces show that idle task is constantly running without sleep. No, they (at

RE: [intel-pstate driver regression] processor frequency very high even if in idle

On 2106.034.01 10:45 Srinivas Pandruvada wrote: > On Fri, 2016-04-01 at 16:06 +0200, Jörg Otte wrote: > > > > > > >> Done. Attached the tracer. >> For me it looks like the previous one of the failing case. > > The traces show that idle task is constantly running without sleep. No, they (at

Re: btrfs_destroy_inode WARN_ON.

On Fri, Apr 01, 2016 at 02:12:27PM -0400, Dave Jones wrote: > BUG: workqueue lockup - pool cpus=1 node=0 flags=0x0 nice=0 stuck for 30s! > Showing busy workqueues and worker pools: > workqueue events: flags=0x0 > pwq 6: cpus=3 node=0 flags=0x0 nice=0 active=1/256 > pending:

Re: btrfs_destroy_inode WARN_ON.

On Fri, Apr 01, 2016 at 02:12:27PM -0400, Dave Jones wrote: > BUG: workqueue lockup - pool cpus=1 node=0 flags=0x0 nice=0 stuck for 30s! > Showing busy workqueues and worker pools: > workqueue events: flags=0x0 > pwq 6: cpus=3 node=0 flags=0x0 nice=0 active=1/256 > pending:

Re: Question on rhashtable in worst-case scenario.

On 03/31/2016 05:46 PM, Herbert Xu wrote: On Thu, Mar 31, 2016 at 05:29:59PM +0200, Johannes Berg wrote: Does removing this completely disable the "-EEXIST" error? I can't say I fully understand the elasticity stuff in __rhashtable_insert_fast(). What EEXIST error are you talking about? The

Re: Question on rhashtable in worst-case scenario.

On 03/31/2016 05:46 PM, Herbert Xu wrote: On Thu, Mar 31, 2016 at 05:29:59PM +0200, Johannes Berg wrote: Does removing this completely disable the "-EEXIST" error? I can't say I fully understand the elasticity stuff in __rhashtable_insert_fast(). What EEXIST error are you talking about? The

Re: [PATCH v3 2/2] usb:dwc3: pass arch data to xhci-hcd child

+Arnd, RMK, On 4/1/2016 4:57 AM, Felipe Balbi wrote: Hi, Grygorii Strashko writes: On 04/01/2016 01:20 PM, Felipe Balbi wrote: [...] commit 7ace8fc8219e4cbbfd5b4790390d9a01a2541cdf Author: Yoshihiro Shimoda Date: Mon Jul 13

Re: [PATCH v3 2/2] usb:dwc3: pass arch data to xhci-hcd child

+Arnd, RMK, On 4/1/2016 4:57 AM, Felipe Balbi wrote: Hi, Grygorii Strashko writes: On 04/01/2016 01:20 PM, Felipe Balbi wrote: [...] commit 7ace8fc8219e4cbbfd5b4790390d9a01a2541cdf Author: Yoshihiro Shimoda Date: Mon Jul 13 18:10:05 2015 +0900 usb: gadget: udc: core: Fix

Re: [PATCH v6 7/7][Resend] cpufreq: schedutil: New governor based on scheduler utilization data

On 03/31/2016 05:32 AM, Rafael J. Wysocki wrote: > On Thu, Mar 31, 2016 at 2:24 PM, Peter Zijlstra wrote: >> On Mon, Mar 28, 2016 at 11:17:44AM -0700, Steve Muckle wrote: >>> The scenario I'm contemplating is that while a CPU-intensive task is >>> running a thermal interrupt

Re: [PATCH v6 7/7][Resend] cpufreq: schedutil: New governor based on scheduler utilization data

On 03/31/2016 05:32 AM, Rafael J. Wysocki wrote: > On Thu, Mar 31, 2016 at 2:24 PM, Peter Zijlstra wrote: >> On Mon, Mar 28, 2016 at 11:17:44AM -0700, Steve Muckle wrote: >>> The scenario I'm contemplating is that while a CPU-intensive task is >>> running a thermal interrupt goes off. The driver

Re: btrfs_destroy_inode WARN_ON.

On Sun, Mar 27, 2016 at 09:14:00PM -0400, Dave Jones wrote: > > WARNING: CPU: 2 PID: 32570 at fs/btrfs/inode.c:9261 > btrfs_destroy_inode+0x389/0x3f0 [btrfs] > > CPU: 2 PID: 32570 Comm: rm Not tainted 4.5.0-think+ #14 > > c039baf9 ef721ef0 88025966fc08

Re: btrfs_destroy_inode WARN_ON.

On Sun, Mar 27, 2016 at 09:14:00PM -0400, Dave Jones wrote: > > WARNING: CPU: 2 PID: 32570 at fs/btrfs/inode.c:9261 > btrfs_destroy_inode+0x389/0x3f0 [btrfs] > > CPU: 2 PID: 32570 Comm: rm Not tainted 4.5.0-think+ #14 > > c039baf9 ef721ef0 88025966fc08

Re: [RFC PATCH 6/6] ppc: ebpf/jit: Implement JIT compiler for extended BPF

On 4/1/16 2:58 AM, Naveen N. Rao wrote: PPC64 eBPF JIT compiler. Works for both ABIv1 and ABIv2. Enable with: echo 1 > /proc/sys/net/core/bpf_jit_enable or echo 2 > /proc/sys/net/core/bpf_jit_enable ... to see the generated JIT code. This can further be processed with tools/net/bpf_jit_disasm.

Re: [RFC PATCH 6/6] ppc: ebpf/jit: Implement JIT compiler for extended BPF

On 4/1/16 2:58 AM, Naveen N. Rao wrote: PPC64 eBPF JIT compiler. Works for both ABIv1 and ABIv2. Enable with: echo 1 > /proc/sys/net/core/bpf_jit_enable or echo 2 > /proc/sys/net/core/bpf_jit_enable ... to see the generated JIT code. This can further be processed with tools/net/bpf_jit_disasm.

Re: [PATCH] iio: imu: Add initial support for Bosch BMI160

Hi Daniel, [auto build test WARNING on iio/togreg] [also build test WARNING on v4.6-rc1 next-20160401] [if your patch is applied to the wrong git tree, please drop us a note to help improving the system] url: https://github.com/0day-ci/linux/commits/Daniel-Baluta/iio-imu-Add-initial-support

Re: [PATCH] iio: imu: Add initial support for Bosch BMI160

Hi Daniel, [auto build test WARNING on iio/togreg] [also build test WARNING on v4.6-rc1 next-20160401] [if your patch is applied to the wrong git tree, please drop us a note to help improving the system] url: https://github.com/0day-ci/linux/commits/Daniel-Baluta/iio-imu-Add-initial-support

Re: [PATCH] sched/clock: Remove pointless test in cpu_clock/local_clock

On 04/01/2016 05:10 PM, Peter Zijlstra wrote: On Fri, Apr 01, 2016 at 03:46:48PM +0200, Daniel Lezcano wrote: Remove the duplicate test by directly calling sched_clock_cpu() and let the static key act in this function instead. We can assume gcc is smart enough to inline

Re: [PATCH] sched/clock: Remove pointless test in cpu_clock/local_clock

On 04/01/2016 05:10 PM, Peter Zijlstra wrote: On Fri, Apr 01, 2016 at 03:46:48PM +0200, Daniel Lezcano wrote: Remove the duplicate test by directly calling sched_clock_cpu() and let the static key act in this function instead. We can assume gcc is smart enough to inline

Re: [PATCH 4/4] samples/bpf: Enable powerpc support

On 4/1/16 7:41 AM, Naveen N. Rao wrote: On 2016/03/31 10:52AM, Alexei Starovoitov wrote: On 3/31/16 4:25 AM, Naveen N. Rao wrote: ... + +#ifdef __powerpc__ +#define BPF_KPROBE_READ_RET_IP(ip, ctx){ (ip) = (ctx)->link; } +#define BPF_KRETPROBE_READ_RET_IP(ip, ctx)

Re: [PATCH 4/4] samples/bpf: Enable powerpc support

On 4/1/16 7:41 AM, Naveen N. Rao wrote: On 2016/03/31 10:52AM, Alexei Starovoitov wrote: On 3/31/16 4:25 AM, Naveen N. Rao wrote: ... + +#ifdef __powerpc__ +#define BPF_KPROBE_READ_RET_IP(ip, ctx){ (ip) = (ctx)->link; } +#define BPF_KRETPROBE_READ_RET_IP(ip, ctx)

Re: [PATCH 2/4] samples/bpf: Use llc in PATH, rather than a hardcoded value

On 4/1/16 7:37 AM, Naveen N. Rao wrote: On 2016/03/31 08:19PM, Daniel Borkmann wrote: On 03/31/2016 07:46 PM, Alexei Starovoitov wrote: On 3/31/16 4:25 AM, Naveen N. Rao wrote: clang $(NOSTDINC_FLAGS) $(LINUXINCLUDE) $(EXTRA_CFLAGS) \ -D__KERNEL__ -D__ASM_SYSREG_H

Re: [PATCH 2/4] samples/bpf: Use llc in PATH, rather than a hardcoded value

On 4/1/16 7:37 AM, Naveen N. Rao wrote: On 2016/03/31 08:19PM, Daniel Borkmann wrote: On 03/31/2016 07:46 PM, Alexei Starovoitov wrote: On 3/31/16 4:25 AM, Naveen N. Rao wrote: clang $(NOSTDINC_FLAGS) $(LINUXINCLUDE) $(EXTRA_CFLAGS) \ -D__KERNEL__ -D__ASM_SYSREG_H

Re: [PATCH 11/11] ARM: dts: s5p: Fix DTC unit name warnings in S5Pv210 boards

Hello Krzysztof, On 04/01/2016 02:57 AM, Krzysztof Kozlowski wrote: > Fix following DTC warnings in S5Pv210 boards: > > Warning (unit_address_vs_reg): Node /memory has a reg or ranges property, but > no unit name > Warning (unit_address_vs_reg): Node >

Re: [PATCH 11/11] ARM: dts: s5p: Fix DTC unit name warnings in S5Pv210 boards

Hello Krzysztof, On 04/01/2016 02:57 AM, Krzysztof Kozlowski wrote: > Fix following DTC warnings in S5Pv210 boards: > > Warning (unit_address_vs_reg): Node /memory has a reg or ranges property, but > no unit name > Warning (unit_address_vs_reg): Node >

Re: [Update][PATCH v7 7/7] cpufreq: schedutil: New governor based on scheduler utilization data

On 03/29/2016 07:00 PM, Rafael J. Wysocki wrote: ... > +config CPU_FREQ_GOV_SCHEDUTIL > + tristate "'schedutil' cpufreq policy governor" > + depends on CPU_FREQ > + select CPU_FREQ_GOV_ATTR_SET > + select IRQ_WORK > + help > + This governor makes decisions based on the

Re: [Update][PATCH v7 7/7] cpufreq: schedutil: New governor based on scheduler utilization data

On 03/29/2016 07:00 PM, Rafael J. Wysocki wrote: ... > +config CPU_FREQ_GOV_SCHEDUTIL > + tristate "'schedutil' cpufreq policy governor" > + depends on CPU_FREQ > + select CPU_FREQ_GOV_ATTR_SET > + select IRQ_WORK > + help > + This governor makes decisions based on the

Re: [PATCH 10/11] ARM: dts: exynos: Fix DTC unit name warnings in Exynos5440

Hello Krzysztof, On 04/01/2016 02:57 AM, Krzysztof Kozlowski wrote: > Fix following DTC warnings in Exynos5440 boards: > > Warning (unit_address_vs_reg): Node /memory has a reg or ranges property, but > no unit name > Warning (unit_address_vs_reg): Node /pinctrl has a reg or ranges property, >

Re: [PATCH 10/11] ARM: dts: exynos: Fix DTC unit name warnings in Exynos5440

Hello Krzysztof, On 04/01/2016 02:57 AM, Krzysztof Kozlowski wrote: > Fix following DTC warnings in Exynos5440 boards: > > Warning (unit_address_vs_reg): Node /memory has a reg or ranges property, but > no unit name > Warning (unit_address_vs_reg): Node /pinctrl has a reg or ranges property, >

Re: [intel-pstate driver regression] processor frequency very high even if in idle

On Fri, 2016-04-01 at 16:06 +0200, Jörg Otte wrote: > 2016-04-01 14:40 GMT+02:00 Rafael J. Wysocki : > > > > On Friday, April 01, 2016 11:20:42 AM Jörg Otte wrote: > > > > > > 2016-03-31 17:43 GMT+02:00 Rafael J. Wysocki : > > > > > > > > On Thursday,

Re: [intel-pstate driver regression] processor frequency very high even if in idle

On Fri, 2016-04-01 at 16:06 +0200, Jörg Otte wrote: > 2016-04-01 14:40 GMT+02:00 Rafael J. Wysocki : > > > > On Friday, April 01, 2016 11:20:42 AM Jörg Otte wrote: > > > > > > 2016-03-31 17:43 GMT+02:00 Rafael J. Wysocki : > > > > > > > > On Thursday, March 31, 2016 05:25:18 PM Jörg Otte wrote:

Re: [PATCH] s390/kexec: Consolidate crash_map/unmap_reserved_pages() and arch_kexec_protect(unprotect)_crashkres()

Hello Xunlei again, Some initial comments below... On Wed, 30 Mar 2016 19:47:21 +0800 Xunlei Pang wrote: > Commit 3f625002581b ("kexec: introduce a protection mechanism > for the crashkernel reserved memory") is a similar mechanism > for protecting the crash kernel reserved

Re: [PATCH] s390/kexec: Consolidate crash_map/unmap_reserved_pages() and arch_kexec_protect(unprotect)_crashkres()

Hello Xunlei again, Some initial comments below... On Wed, 30 Mar 2016 19:47:21 +0800 Xunlei Pang wrote: > Commit 3f625002581b ("kexec: introduce a protection mechanism > for the crashkernel reserved memory") is a similar mechanism > for protecting the crash kernel reserved memory to previous

Re: [PATCH v2] iov_iter: Fix out-of-bound access in iov_iter_advance()

On Fri, Apr 01, 2016 at 05:02:04PM +0200, Takashi Iwai wrote: > Currently, iov_iter_advance() just calls iterate_and_advance() macro > as is, even if size=0 is passed. Usually it is OK to pass size=0 to > the macro. However, when the iov_iter has been already advanced to > the end of the array,

Re: [PATCH v2] iov_iter: Fix out-of-bound access in iov_iter_advance()

On Fri, Apr 01, 2016 at 05:02:04PM +0200, Takashi Iwai wrote: > Currently, iov_iter_advance() just calls iterate_and_advance() macro > as is, even if size=0 is passed. Usually it is OK to pass size=0 to > the macro. However, when the iov_iter has been already advanced to > the end of the array,

Re: [intel-pstate driver regression] processor frequency very high even if in idle

2016-04-01 18:46 GMT+02:00 Jörg Otte : > 2016-04-01 17:20 GMT+02:00 Doug Smythies : >> On 2016.04.01 05:40 Rafael J. Wysocki wrote: >>> On Friday, April 01, 2016 11:20:42 AM Jörg Otte wrote: 2016-03-31 17:43 GMT+02:00 Rafael J. Wysocki

Re: [intel-pstate driver regression] processor frequency very high even if in idle

2016-04-01 18:46 GMT+02:00 Jörg Otte : > 2016-04-01 17:20 GMT+02:00 Doug Smythies : >> On 2016.04.01 05:40 Rafael J. Wysocki wrote: >>> On Friday, April 01, 2016 11:20:42 AM Jörg Otte wrote: 2016-03-31 17:43 GMT+02:00 Rafael J. Wysocki : > On Thursday, March 31, 2016 05:25:18 PM Jörg Otte

Re: [PATCH 09/11] ARM: dts: exynos: Fix DTC unit name warnings in SMDK5420

Hello Krzysztof, On 04/01/2016 02:57 AM, Krzysztof Kozlowski wrote: > Fix following DTC warnings in Exynos5420 SMDK5420: > > Warning (unit_address_vs_reg): Node > /dp-controller@145B/display-timings/timing@0 has a unit name, but no reg > property > > Signed-off-by: Krzysztof Kozlowski

Re: [PATCH 09/11] ARM: dts: exynos: Fix DTC unit name warnings in SMDK5420

Hello Krzysztof, On 04/01/2016 02:57 AM, Krzysztof Kozlowski wrote: > Fix following DTC warnings in Exynos5420 SMDK5420: > > Warning (unit_address_vs_reg): Node > /dp-controller@145B/display-timings/timing@0 has a unit name, but no reg > property > > Signed-off-by: Krzysztof Kozlowski >

Re: [PATCH 08/11] ARM: dts: exynos: Fix DTC unit name warnings in Peach Pit

Hello Krzysztof, On 04/01/2016 02:57 AM, Krzysztof Kozlowski wrote: > Fix following DTC warnings in Exynos5420 Peach Pit: > > Warning (unit_address_vs_reg): Node /dp-controller@145B/ports/port@0 has > a unit name, but no reg property > Warning (unit_address_vs_reg): Node

Re: [PATCH 08/11] ARM: dts: exynos: Fix DTC unit name warnings in Peach Pit

Hello Krzysztof, On 04/01/2016 02:57 AM, Krzysztof Kozlowski wrote: > Fix following DTC warnings in Exynos5420 Peach Pit: > > Warning (unit_address_vs_reg): Node /dp-controller@145B/ports/port@0 has > a unit name, but no reg property > Warning (unit_address_vs_reg): Node

Re: [PATCH 07/11] ARM: dts: exynos: Fix DTC unit name warnings in Exynos542x

Hello Krzysztof, On 04/01/2016 02:57 AM, Krzysztof Kozlowski wrote: > Fix following DTC warnings in all Exynos542x/5800 boards: > > Warning (unit_address_vs_reg): Node /video-phy@10040728 has a unit name, but > no reg property > Warning (unit_address_vs_reg): Node /video-phy@10040714 has a unit

Re: [PATCH 07/11] ARM: dts: exynos: Fix DTC unit name warnings in Exynos542x

Hello Krzysztof, On 04/01/2016 02:57 AM, Krzysztof Kozlowski wrote: > Fix following DTC warnings in all Exynos542x/5800 boards: > > Warning (unit_address_vs_reg): Node /video-phy@10040728 has a unit name, but > no reg property > Warning (unit_address_vs_reg): Node /video-phy@10040714 has a unit

Re: [PATCH 06/11] ARM: dts: exynos: Fix DTC unit name warnings in Exynos5250

Hello Krzysztof, Patch looks good to me, I have just one question below: On 04/01/2016 02:57 AM, Krzysztof Kozlowski wrote: > Fix following DTC warnings in all Exynos5250 boards: > > Warning (unit_address_vs_reg): Node > /dp-controller@145B/display-timings/timing@0 has a unit name, but no

Re: [PATCH 06/11] ARM: dts: exynos: Fix DTC unit name warnings in Exynos5250

Hello Krzysztof, Patch looks good to me, I have just one question below: On 04/01/2016 02:57 AM, Krzysztof Kozlowski wrote: > Fix following DTC warnings in all Exynos5250 boards: > > Warning (unit_address_vs_reg): Node > /dp-controller@145B/display-timings/timing@0 has a unit name, but no

Re: [PATCH 1/2] Documentation: fsl-quadspi: Add fsl, ls1043a-qspi compatible string

On Thu, Mar 31, 2016 at 02:45:00PM +0800, Yuan Yao wrote: > From: Yuan Yao > > new compatible string: "fsl,ls1043a-qspi". > > Signed-off-by: Yuan Yao > --- > Documentation/devicetree/bindings/mtd/fsl-quadspi.txt | 3 ++- > 1 file changed, 2 insertions(+), 1

Re: [PATCH 1/2] Documentation: fsl-quadspi: Add fsl, ls1043a-qspi compatible string

On Thu, Mar 31, 2016 at 02:45:00PM +0800, Yuan Yao wrote: > From: Yuan Yao > > new compatible string: "fsl,ls1043a-qspi". > > Signed-off-by: Yuan Yao > --- > Documentation/devicetree/bindings/mtd/fsl-quadspi.txt | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) There's a typo in the

Re: [PATCH v6 1/3] ASoC: cygnus: Add DT bindings for Broadcom Cygnus audio

On Wed, Mar 30, 2016 at 05:24:44PM -0700, Simran Rai wrote: > From: Simran Rai > > Add bindings for audio driver in Broadcom Cygnus. > > Signed-off-by: Lori Hikichi > Signed-off-by: Simran Rai > Reviewed-by: Ray Jui

Re: [PATCH v6 1/3] ASoC: cygnus: Add DT bindings for Broadcom Cygnus audio

On Wed, Mar 30, 2016 at 05:24:44PM -0700, Simran Rai wrote: > From: Simran Rai > > Add bindings for audio driver in Broadcom Cygnus. > > Signed-off-by: Lori Hikichi > Signed-off-by: Simran Rai > Reviewed-by: Ray Jui > Reviewed-by: Scott Branden > --- >

Re: [PATCH 3/5] dmaengine: mv_xor: add support for Armada 3700 SoC

On Wed, Mar 30, 2016 at 07:35:18PM +0200, Gregory CLEMENT wrote: > From: Marcin Wojtas > > Armada 3700 SoC comprise a single XOR engine compliant with the ones used > in older Marvell SoC's like Armada XP or 38x. The only thing that neededs s/neededs/needs/ > modification is

Re: [PATCH 3/5] dmaengine: mv_xor: add support for Armada 3700 SoC

On Wed, Mar 30, 2016 at 07:35:18PM +0200, Gregory CLEMENT wrote: > From: Marcin Wojtas > > Armada 3700 SoC comprise a single XOR engine compliant with the ones used > in older Marvell SoC's like Armada XP or 38x. The only thing that neededs s/neededs/needs/ > modification is the Mbus

Re: [PATCH 1/3 v2] drm/i2c/adv7511: Add audio support

Hi Jose, Thank you for the patch. On Monday 28 Mar 2016 15:36:09 Jose Abreu wrote: > This patch adds audio support for the ADV7511 HDMI transmitter > using ALSA SoC. > > The code was ported from Analog Devices linux tree from > commit 1770c4a1e32b ("Merge remote-tracking branch >

Re: [PATCH 1/3 v2] drm/i2c/adv7511: Add audio support

Hi Jose, Thank you for the patch. On Monday 28 Mar 2016 15:36:09 Jose Abreu wrote: > This patch adds audio support for the ADV7511 HDMI transmitter > using ALSA SoC. > > The code was ported from Analog Devices linux tree from > commit 1770c4a1e32b ("Merge remote-tracking branch >

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