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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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.
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
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.
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) ==
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) ==
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
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
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
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
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
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
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
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
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:
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
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
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
* 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
* 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.
> > > > >
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
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
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:
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:
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
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
+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
+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
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
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
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
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
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.
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.
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
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
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
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
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)
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)
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
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
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
>
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
>
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
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
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,
>
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,
>
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,
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:
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
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
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,
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,
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
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
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
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
>
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
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
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
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
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
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
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
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
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
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
> ---
>
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
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
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
>
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
>
701 - 800 of 1798 matches
Mail list logo