[PATCH v3 05/20] remoteproc: core: Add function to over-ride current resource table

From: Lee Jones Most of the new resource table handling function are now in place, so it's time to put it all together. Once new resource table information has been requested, the structures will be held in a holding pen until boot-time. During boot-time

[PATCH v3 05/20] remoteproc: core: Add function to over-ride current resource table

From: Lee Jones Most of the new resource table handling function are now in place, so it's time to put it all together. Once new resource table information has been requested, the structures will be held in a holding pen until boot-time. During boot-time rproc_apply_resource_overrides() will

Re: [PATCH v2 2/4] Add enabling of the R3 MWAIT during boot for KNL

On 10/12/2016 05:16 AM, Grzegorz Andrejczuk wrote: > @@ -211,6 +219,25 @@ static void early_init_intel(struct cpuinfo_x86 *c) > } > > check_mpx_erratum(c); > + > + /* > + * Setting ring 3 MONITOR/MWAIT for all threads > + * when CPU is Xeon Phi Family x200 > + * This

Re: [PATCH v2 2/4] Add enabling of the R3 MWAIT during boot for KNL

On 10/12/2016 05:16 AM, Grzegorz Andrejczuk wrote: > @@ -211,6 +219,25 @@ static void early_init_intel(struct cpuinfo_x86 *c) > } > > check_mpx_erratum(c); > + > + /* > + * Setting ring 3 MONITOR/MWAIT for all threads > + * when CPU is Xeon Phi Family x200 > + * This

[PATCH resent 03/34] [media] DaVinci-VPBE: Adjust 16 checks for null pointers

From: Markus Elfring Date: Tue, 11 Oct 2016 13:37:10 +0200 The script "checkpatch.pl" pointed information out like the following. Comparison to NULL could be written ... Thus fix the affected source code places. Signed-off-by: Markus Elfring

[PATCH resent 03/34] [media] DaVinci-VPBE: Adjust 16 checks for null pointers

From: Markus Elfring Date: Tue, 11 Oct 2016 13:37:10 +0200 The script "checkpatch.pl" pointed information out like the following. Comparison to NULL could be written ... Thus fix the affected source code places. Signed-off-by: Markus Elfring --- Another send try because of the following

[PATCH resent 27/34] [media] DaVinci-VPIF-Capture: Adjust ten checks for null pointers

From: Markus Elfring Date: Wed, 12 Oct 2016 15:20:34 +0200 The script "checkpatch.pl" pointed information out like the following. Comparison to NULL could be written ... Thus fix the affected source code places. Signed-off-by: Markus Elfring

[PATCH resent 27/34] [media] DaVinci-VPIF-Capture: Adjust ten checks for null pointers

From: Markus Elfring Date: Wed, 12 Oct 2016 15:20:34 +0200 The script "checkpatch.pl" pointed information out like the following. Comparison to NULL could be written ... Thus fix the affected source code places. Signed-off-by: Markus Elfring --- Another send try because of the following

[PATCH] mfd: intel-lpss: Do not put device in reset state on suspend

Commit 41a3da2b8e163 ("mfd: intel-lpss: Save register context on suspend") saved the register context while going to suspend and also put the device in reset state. Due to the resetting of device, system cannot enter S3/S0ix states when no_console_suspend flag is enabled. The system and serial

[PATCH] mfd: intel-lpss: Do not put device in reset state on suspend

Commit 41a3da2b8e163 ("mfd: intel-lpss: Save register context on suspend") saved the register context while going to suspend and also put the device in reset state. Due to the resetting of device, system cannot enter S3/S0ix states when no_console_suspend flag is enabled. The system and serial

[GIT PULL] pwm: Changes for v4.9-rc1

Hi Linus, The following changes since commit 29b4817d4018df78086157ea3a55c1d9424a7cfc: Linux 4.8-rc1 (2016-08-07 18:18:00 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/thierry.reding/linux-pwm.git tags/pwm/for-4.9-rc1 for you to fetch

[GIT PULL] pwm: Changes for v4.9-rc1

Hi Linus, The following changes since commit 29b4817d4018df78086157ea3a55c1d9424a7cfc: Linux 4.8-rc1 (2016-08-07 18:18:00 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/thierry.reding/linux-pwm.git tags/pwm/for-4.9-rc1 for you to fetch

Re: [PATCH v8 2/2] clocksource: add J-Core timer/clocksource driver

On Wed, Oct 12, 2016 at 11:27:11AM +0200, Daniel Lezcano wrote: > > > Are the CPUs on always-on power down ? > > > > For now they are always on and don't even have the sleep instruction > > (i.e. stop cpu clock until interrupt) implemented. Adding sleep will > > be the first power-saving step,

Re: [PATCH v8 2/2] clocksource: add J-Core timer/clocksource driver

On Wed, Oct 12, 2016 at 11:27:11AM +0200, Daniel Lezcano wrote: > > > Are the CPUs on always-on power down ? > > > > For now they are always on and don't even have the sleep instruction > > (i.e. stop cpu clock until interrupt) implemented. Adding sleep will > > be the first power-saving step,

[PATCH v3 06/20] remoteproc: core: Associate action to resource request

With new rproc_request_resource API, rproc driver has now the capability to provide resources to remoteproc in order to modify firmware resource table. But in some cases, other operations are needed like compatibility check between resources defined at firmware level and those handled by rproc

[PATCH v3 06/20] remoteproc: core: Associate action to resource request

With new rproc_request_resource API, rproc driver has now the capability to provide resources to remoteproc in order to modify firmware resource table. But in some cases, other operations are needed like compatibility check between resources defined at firmware level and those handled by rproc

Re: [PATCH 3.4 000/125] 3.4.113-rc1 review

On Wed, Oct 12, 2016 at 08:33:20PM +0800, l...@kernel.org wrote: > From: Zefan Li > > This is the start of the stable review cycle for the 3.4.113 release. > There are 125 patches in this series, all will be posted as a response > to this one. If anyone has any issues with

Re: [PATCH 3.4 000/125] 3.4.113-rc1 review

On Wed, Oct 12, 2016 at 08:33:20PM +0800, l...@kernel.org wrote: > From: Zefan Li > > This is the start of the stable review cycle for the 3.4.113 release. > There are 125 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied,

Re: [PATCH v1.1 1/2] watchdog: loongson1: Add Loongson1 SoC watchdog driver

On Thu, Oct 13, 2016 at 12:37:44AM +0800, Yang Ling wrote: > On Tue, Oct 11, 2016 at 07:54:03AM -0700, Guenter Roeck wrote: > > On 10/11/2016 07:10 AM, Yang Ling wrote: > > >Add watchdog timer specific driver for Loongson1 SoC. > > > > > >Signed-off-by: Yang Ling > > > > >

Re: [PATCH v1.1 1/2] watchdog: loongson1: Add Loongson1 SoC watchdog driver

On Thu, Oct 13, 2016 at 12:37:44AM +0800, Yang Ling wrote: > On Tue, Oct 11, 2016 at 07:54:03AM -0700, Guenter Roeck wrote: > > On 10/11/2016 07:10 AM, Yang Ling wrote: > > >Add watchdog timer specific driver for Loongson1 SoC. > > > > > >Signed-off-by: Yang Ling > > > > > >--- > > >V1.1: > > >

[PATCH v3 14/20] remoteproc: core: Add force mode to resource amending function

This patch adds force mode to rproc_update_resource_table_entry function. When force is unset, resource will be updated only if no specific addresses are requested by firmware. When force is set, resource is directly overwritten. Signed-off-by: Loic Pallardy ---

Re: [v2] timers: Fix usleep_range() in the context of wake_up_process()

On Wed, Oct 12, 2016 at 09:27:35AM -0700, Doug Anderson wrote: > Hi, > > On Wed, Oct 12, 2016 at 9:03 AM, Guenter Roeck wrote: > > drivers/iio/accel/kxcjk-1013.c: kxcjk1013_runtime_resume() > > drivers/iio/accel/bmc150-accel-core.c:bmc150_accel_runtime_resume() > >

[PATCH v3 15/20] remoteproc: core: Append resource only if .resource_table section is large enough

To guarantee remoteproc won't overwrite firmware data when copying back modified resource table, rproc_add_resource_table_entry verifies first that .resource_table elf section is large enough to support new resource appending. Signed-off-by: Loic Pallardy ---

[PATCH v3 14/20] remoteproc: core: Add force mode to resource amending function

This patch adds force mode to rproc_update_resource_table_entry function. When force is unset, resource will be updated only if no specific addresses are requested by firmware. When force is set, resource is directly overwritten. Signed-off-by: Loic Pallardy ---

Re: [v2] timers: Fix usleep_range() in the context of wake_up_process()

On Wed, Oct 12, 2016 at 09:27:35AM -0700, Doug Anderson wrote: > Hi, > > On Wed, Oct 12, 2016 at 9:03 AM, Guenter Roeck wrote: > > drivers/iio/accel/kxcjk-1013.c: kxcjk1013_runtime_resume() > > drivers/iio/accel/bmc150-accel-core.c:bmc150_accel_runtime_resume() > >

[PATCH v3 15/20] remoteproc: core: Append resource only if .resource_table section is large enough

To guarantee remoteproc won't overwrite firmware data when copying back modified resource table, rproc_add_resource_table_entry verifies first that .resource_table elf section is large enough to support new resource appending. Signed-off-by: Loic Pallardy ---

Re: [PATCH] gpio / ACPI: fix returned error from acpi_dev_gpio_irq_get()

On Wed, Oct 12, 2016 at 6:40 PM, Benjamin Tissoires wrote: > From: David Arcari > > acpi_dev_gpio_irq_get() currently ignores the error returned > by acpi_get_gpiod_by_index() and overwrites it with -ENOENT. > > Problem is this error can be

Re: [PATCH] gpio / ACPI: fix returned error from acpi_dev_gpio_irq_get()

On Wed, Oct 12, 2016 at 6:40 PM, Benjamin Tissoires wrote: > From: David Arcari > > acpi_dev_gpio_irq_get() currently ignores the error returned > by acpi_get_gpiod_by_index() and overwrites it with -ENOENT. > > Problem is this error can be -EPROBE_DEFER, which just blows > up some drivers when

Re: linux.git: printk() problem

On Wed, Oct 12, 2016 at 9:16 AM, Joe Perches wrote: >> (but with the new world order you actually *can* combine KERN_CONT >> with a loglevel, so that if the beginning od the line got flushed, the >> continuation can still be printed with the right log level). > > I think that

[PATCH v3 11/20] remoteproc: core: Correction carveout name comparison in rproc_update_resource_table_entry

As old and new carveout name length may be different and the two names may have a common part, name comparison must cover the complete name field. Limit strncmp to carveout name length, i.e. 32 Bytes. Signed-off-by: Loic Pallardy --- drivers/remoteproc/remoteproc_core.c |

[PATCH v3 11/20] remoteproc: core: Correction carveout name comparison in rproc_update_resource_table_entry

As old and new carveout name length may be different and the two names may have a common part, name comparison must cover the complete name field. Limit strncmp to carveout name length, i.e. 32 Bytes. Signed-off-by: Loic Pallardy --- drivers/remoteproc/remoteproc_core.c | 3 +-- 1 file changed,

Re: linux.git: printk() problem

On Wed, Oct 12, 2016 at 9:16 AM, Joe Perches wrote: >> (but with the new world order you actually *can* combine KERN_CONT >> with a loglevel, so that if the beginning od the line got flushed, the >> continuation can still be printed with the right log level). > > I think that might not be a good

Re: [PATCH v5 5/9] x86/sysctl: Add sysctl for ITMT scheduling feature

On Thu, Oct 06, 2016 at 01:13:08PM +0200, Thomas Gleixner wrote: > On Wed, 5 Oct 2016, Tim Chen wrote: > > On Wed, 2016-10-05 at 16:35 +0200, Thomas Gleixner wrote: > > > > + if (itmt_supported) { > > > > + itmt_sysctl_header = > > > > +

Re: [PATCH v5 5/9] x86/sysctl: Add sysctl for ITMT scheduling feature

On Thu, Oct 06, 2016 at 01:13:08PM +0200, Thomas Gleixner wrote: > On Wed, 5 Oct 2016, Tim Chen wrote: > > On Wed, 2016-10-05 at 16:35 +0200, Thomas Gleixner wrote: > > > > + if (itmt_supported) { > > > > + itmt_sysctl_header = > > > > +

[PATCH v3 12/20] remoteproc: core: Add function to verify an existing resource in rsc table

When a firmware is build, it can be loaded with a resource usually detailing shared; memory, virtual device, trace log information etc. However, some SoCs or platforms require some hard-coded information. Information may be fixed on both sides: firmware and rproc. Until now, no method exists which

[PATCH v3 12/20] remoteproc: core: Add function to verify an existing resource in rsc table

When a firmware is build, it can be loaded with a resource usually detailing shared; memory, virtual device, trace log information etc. However, some SoCs or platforms require some hard-coded information. Information may be fixed on both sides: firmware and rproc. Until now, no method exists which

Re: [v2] timers: Fix usleep_range() in the context of wake_up_process()

Hi, On Wed, Oct 12, 2016 at 9:03 AM, Guenter Roeck wrote: > drivers/iio/accel/kxcjk-1013.c: kxcjk1013_runtime_resume() > drivers/iio/accel/bmc150-accel-core.c:bmc150_accel_runtime_resume() > drivers/iio/accel/mma8452.c:mma8452_runtime_resume() >

Re: [v2] timers: Fix usleep_range() in the context of wake_up_process()

Hi, On Wed, Oct 12, 2016 at 9:03 AM, Guenter Roeck wrote: > drivers/iio/accel/kxcjk-1013.c: kxcjk1013_runtime_resume() > drivers/iio/accel/bmc150-accel-core.c:bmc150_accel_runtime_resume() > drivers/iio/accel/mma8452.c:mma8452_runtime_resume() > drivers/iio/accel/mma9551_core.c:mma9551_sleep()

Re: [GIT PULL] xfs: shared data extents support for 4.9-rc1

On Wed, Oct 12, 2016 at 11:18:49PM +1100, Dave Chinner wrote: > Hi Linus, > > This is the second part of the XFS updates for this merge cycle. > This pullreq contains the new shared data extents feature for XFS, > and can be found at: > >

Re: [GIT PULL] xfs: shared data extents support for 4.9-rc1

On Wed, Oct 12, 2016 at 11:18:49PM +1100, Dave Chinner wrote: > Hi Linus, > > This is the second part of the XFS updates for this merge cycle. > This pullreq contains the new shared data extents feature for XFS, > and can be found at: > >

[PATCH] gpio / ACPI: fix returned error from acpi_dev_gpio_irq_get()

From: David Arcari acpi_dev_gpio_irq_get() currently ignores the error returned by acpi_get_gpiod_by_index() and overwrites it with -ENOENT. Problem is this error can be -EPROBE_DEFER, which just blows up some drivers when the module ordering is not correct. Cc:

[PATCH] gpio / ACPI: fix returned error from acpi_dev_gpio_irq_get()

From: David Arcari acpi_dev_gpio_irq_get() currently ignores the error returned by acpi_get_gpiod_by_index() and overwrites it with -ENOENT. Problem is this error can be -EPROBE_DEFER, which just blows up some drivers when the module ordering is not correct. Cc: sta...@vger.kernel.org

Re: [RFC] net: phy: smsc: Disable auto-negotiation on startup

On Wed, Oct 12, 2016 at 02:13:06AM -0700, Florian Fainelli wrote: > On 10/10/2016 10:41 AM, Kyle Roeschley wrote: > > Because the SMSC PHY completes auto-negotiation before the driver is > > ready to handle interrupts, the PHY state machine never realizes that we > > have a link. Clear the

Re: [RFC] net: phy: smsc: Disable auto-negotiation on startup

On Wed, Oct 12, 2016 at 02:13:06AM -0700, Florian Fainelli wrote: > On 10/10/2016 10:41 AM, Kyle Roeschley wrote: > > Because the SMSC PHY completes auto-negotiation before the driver is > > ready to handle interrupts, the PHY state machine never realizes that we > > have a link. Clear the

Re: [PATCH v1.1 1/2] watchdog: loongson1: Add Loongson1 SoC watchdog driver

On Tue, Oct 11, 2016 at 07:54:03AM -0700, Guenter Roeck wrote: > On 10/11/2016 07:10 AM, Yang Ling wrote: > >Add watchdog timer specific driver for Loongson1 SoC. > > > >Signed-off-by: Yang Ling > > > >--- > >V1.1: > > Add a little debugging information. > >--- > >

Re: igb driver can cause cache invalidation of non-owned memory?

>>> To get some throughput improvement, I propose removal of that >>> sync_for_device() before reusing buffer. Will you accept such a patch ;) >> >> Not one that gets rid of sync_for_device() in the driver. From what I >> can tell there are some DMA APIs that use that to perform the >>

Re: [PATCH v1.1 1/2] watchdog: loongson1: Add Loongson1 SoC watchdog driver

On Tue, Oct 11, 2016 at 07:54:03AM -0700, Guenter Roeck wrote: > On 10/11/2016 07:10 AM, Yang Ling wrote: > >Add watchdog timer specific driver for Loongson1 SoC. > > > >Signed-off-by: Yang Ling > > > >--- > >V1.1: > > Add a little debugging information. > >--- > > drivers/watchdog/Kconfig

Re: igb driver can cause cache invalidation of non-owned memory?

>>> To get some throughput improvement, I propose removal of that >>> sync_for_device() before reusing buffer. Will you accept such a patch ;) >> >> Not one that gets rid of sync_for_device() in the driver. From what I >> can tell there are some DMA APIs that use that to perform the >>

Re: [PATCH] irqchip/jcore: fix lost per-cpu interrupts

On Wed, Oct 12, 2016 at 10:18:02AM +0200, Thomas Gleixner wrote: > On Tue, 11 Oct 2016, Rich Felker wrote: > > On Sun, Oct 09, 2016 at 09:23:58PM +0200, Thomas Gleixner wrote: > > > On Sun, 9 Oct 2016, Rich Felker wrote: > > > > On Sun, Oct 09, 2016 at 01:03:10PM +0200, Thomas Gleixner wrote: > >

Re: [PATCH] irqchip/jcore: fix lost per-cpu interrupts

On Wed, Oct 12, 2016 at 10:18:02AM +0200, Thomas Gleixner wrote: > On Tue, 11 Oct 2016, Rich Felker wrote: > > On Sun, Oct 09, 2016 at 09:23:58PM +0200, Thomas Gleixner wrote: > > > On Sun, 9 Oct 2016, Rich Felker wrote: > > > > On Sun, Oct 09, 2016 at 01:03:10PM +0200, Thomas Gleixner wrote: > >

[PATCH v3 09/20] remoteproc: core: Unify rproc_dump_resource_table debug messages

For coherency with the rest of the function, mention the resource table entry when an invalid resource is detected. Signed-off-by: Loic Pallardy --- drivers/remoteproc/remoteproc_core.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git

[PATCH v3 10/20] remoteproc: core: Call rproc_dump_resource_table only if debug is activated

To reduce CPU usage, limit rproc_dump_resource_table calls only when DEBUG or CONFIG_DYNAMIC_DEBUG flags are activated. Signed-off-by: Loic Pallardy --- drivers/remoteproc/remoteproc_core.c | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git

[PATCH v3 09/20] remoteproc: core: Unify rproc_dump_resource_table debug messages

For coherency with the rest of the function, mention the resource table entry when an invalid resource is detected. Signed-off-by: Loic Pallardy --- drivers/remoteproc/remoteproc_core.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/remoteproc/remoteproc_core.c

[PATCH v3 10/20] remoteproc: core: Call rproc_dump_resource_table only if debug is activated

To reduce CPU usage, limit rproc_dump_resource_table calls only when DEBUG or CONFIG_DYNAMIC_DEBUG flags are activated. Signed-off-by: Loic Pallardy --- drivers/remoteproc/remoteproc_core.c | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git

Re: [PATCH] mm: kmemleak: Ensure that the task stack is not freed during scanning

- Original Message - > From: "Catalin Marinas" > To: linux...@kvack.org > Cc: linux-kernel@vger.kernel.org, "Andrew Morton" > , "Andy Lutomirski" , > "CAI Qian" > Sent: Wednesday, October 12, 2016

Re: [PATCH] mm: kmemleak: Ensure that the task stack is not freed during scanning

- Original Message - > From: "Catalin Marinas" > To: linux...@kvack.org > Cc: linux-kernel@vger.kernel.org, "Andrew Morton" > , "Andy Lutomirski" , > "CAI Qian" > Sent: Wednesday, October 12, 2016 5:57:03 AM > Subject: [PATCH] mm: kmemleak: Ensure that the task stack is not freed

Re: [PATCH v2 2/4] Add enabling of the R3 MWAIT during boot for KNL

On 10/12/2016 06:34 AM, Thomas Gleixner wrote: >> > + if (c->x86 == 6 && >> > + c->x86_model == INTEL_FAM6_XEON_PHI_KNL && >> > + phir3mwait) { >> > + u64 prev; >> > + >> > + rdmsrl(MSR_PHI_MISC_THD_FEATURE, prev); >> > + if ((prev &

Re: [PATCH v2 2/4] Add enabling of the R3 MWAIT during boot for KNL

On 10/12/2016 06:34 AM, Thomas Gleixner wrote: >> > + if (c->x86 == 6 && >> > + c->x86_model == INTEL_FAM6_XEON_PHI_KNL && >> > + phir3mwait) { >> > + u64 prev; >> > + >> > + rdmsrl(MSR_PHI_MISC_THD_FEATURE, prev); >> > + if ((prev &

Re: [PATCH] toshiba-wmi: Fix loading the driver on non Toshiba laptops

*ping* 2016-08-28 11:00 GMT-06:00 Darren Hart : > On Thu, Aug 25, 2016 at 12:50:55PM -0600, Azael Avalos wrote: >> Bug 150611 uncovered that the WMI ID used by the toshiba-wmi driver >> is not Toshiba specific, and as such, the driver was being loaded >> on non Toshiba

[RFC PATCH 2/2] f2fs: fix allocation failure

From: Chao Yu tests/generic/251 of fstest reports a f2fs bug in below message: [ cut here ] invalid opcode: [#1] PREEMPT SMP CPU: 1 PID: 109 Comm: kworker/u8:2 Tainted: GW O4.8.0-rc4+ #22 Hardware name: innotek GmbH

Re: [PATCH] toshiba-wmi: Fix loading the driver on non Toshiba laptops

*ping* 2016-08-28 11:00 GMT-06:00 Darren Hart : > On Thu, Aug 25, 2016 at 12:50:55PM -0600, Azael Avalos wrote: >> Bug 150611 uncovered that the WMI ID used by the toshiba-wmi driver >> is not Toshiba specific, and as such, the driver was being loaded >> on non Toshiba laptops too. >> >> This

[RFC PATCH 2/2] f2fs: fix allocation failure

From: Chao Yu tests/generic/251 of fstest reports a f2fs bug in below message: [ cut here ] invalid opcode: [#1] PREEMPT SMP CPU: 1 PID: 109 Comm: kworker/u8:2 Tainted: GW O4.8.0-rc4+ #22 Hardware name: innotek GmbH VirtualBox/VirtualBox, BIOS

[RFC PATCH 1/2] f2fs: rename f2fs_update_time

From: Chao Yu For readability, no functionality change. Signed-off-by: Chao Yu --- fs/f2fs/checkpoint.c | 2 +- fs/f2fs/data.c | 2 +- fs/f2fs/dir.c| 6 +++--- fs/f2fs/f2fs.h | 2 +- fs/f2fs/file.c | 24

[RFC PATCH 1/2] f2fs: rename f2fs_update_time

From: Chao Yu For readability, no functionality change. Signed-off-by: Chao Yu --- fs/f2fs/checkpoint.c | 2 +- fs/f2fs/data.c | 2 +- fs/f2fs/dir.c| 6 +++--- fs/f2fs/f2fs.h | 2 +- fs/f2fs/file.c | 24 fs/f2fs/super.c | 4 ++--

Re: [PATCH 5/7 v4] sched: propagate asynchrous detach

On 12/10/16 16:45, Vincent Guittot wrote: > On 12 October 2016 at 17:03, Dietmar Eggemann > wrote: >> On 26/09/16 13:19, Vincent Guittot wrote: [...] >>> @@ -6607,6 +6609,10 @@ static void update_blocked_averages(int cpu) >>> >>> if

Re: [PATCH 5/7 v4] sched: propagate asynchrous detach

On 12/10/16 16:45, Vincent Guittot wrote: > On 12 October 2016 at 17:03, Dietmar Eggemann > wrote: >> On 26/09/16 13:19, Vincent Guittot wrote: [...] >>> @@ -6607,6 +6609,10 @@ static void update_blocked_averages(int cpu) >>> >>> if

Re: [Xen-devel] [RFC KERNEL PATCH 0/2] Add Dom0 NVDIMM support for Xen

>>> On 12.10.16 at 17:42, wrote: > On Wed, Oct 12, 2016 at 8:39 AM, Jan Beulich wrote: > On 12.10.16 at 16:58, wrote: >>> On 10/12/16 05:32 -0600, Jan Beulich wrote: >>> On 12.10.16 at 12:33,

Re: [Xen-devel] [RFC KERNEL PATCH 0/2] Add Dom0 NVDIMM support for Xen

>>> On 12.10.16 at 17:42, wrote: > On Wed, Oct 12, 2016 at 8:39 AM, Jan Beulich wrote: > On 12.10.16 at 16:58, wrote: >>> On 10/12/16 05:32 -0600, Jan Beulich wrote: >>> On 12.10.16 at 12:33, wrote: > The layout is shown as the following diagram. > >

Re: [v4.8-rc1 Regression] sched/fair: Apply more PELT fixes

On 10/12/2016 08:20 AM, Vincent Guittot wrote: > On 8 October 2016 at 13:49, Mike Galbraith wrote: >> On Sat, 2016-10-08 at 13:37 +0200, Vincent Guittot wrote: >>> On 8 October 2016 at 10:39, Ingo Molnar wrote: * Peter Zijlstra wrote:

Re: [v4.8-rc1 Regression] sched/fair: Apply more PELT fixes

On 10/12/2016 08:20 AM, Vincent Guittot wrote: > On 8 October 2016 at 13:49, Mike Galbraith wrote: >> On Sat, 2016-10-08 at 13:37 +0200, Vincent Guittot wrote: >>> On 8 October 2016 at 10:39, Ingo Molnar wrote: * Peter Zijlstra wrote: > On Fri, Oct 07, 2016 at 03:38:23PM -0400,

[PATCH v3 08/20] remoteproc: core: Complete VDEV support in rproc_dump_resource_table function

Add dump of cfg field of vdev struct. Signed-off-by: Loic Pallardy --- drivers/remoteproc/remoteproc_core.c | 13 + 1 file changed, 13 insertions(+) diff --git a/drivers/remoteproc/remoteproc_core.c b/drivers/remoteproc/remoteproc_core.c index

[PATCH v3 08/20] remoteproc: core: Complete VDEV support in rproc_dump_resource_table function

Add dump of cfg field of vdev struct. Signed-off-by: Loic Pallardy --- drivers/remoteproc/remoteproc_core.c | 13 + 1 file changed, 13 insertions(+) diff --git a/drivers/remoteproc/remoteproc_core.c b/drivers/remoteproc/remoteproc_core.c index ce62546..ae8e934 100644 ---

Re: [Xen-devel] [RFC KERNEL PATCH 0/2] Add Dom0 NVDIMM support for Xen

On Wed, Oct 12, 2016 at 9:01 AM, Jan Beulich wrote: On 12.10.16 at 17:42, wrote: >> On Wed, Oct 12, 2016 at 8:39 AM, Jan Beulich wrote: >> On 12.10.16 at 16:58, wrote: On 10/12/16 05:32

Re: [Xen-devel] [RFC KERNEL PATCH 0/2] Add Dom0 NVDIMM support for Xen

On Wed, Oct 12, 2016 at 9:01 AM, Jan Beulich wrote: On 12.10.16 at 17:42, wrote: >> On Wed, Oct 12, 2016 at 8:39 AM, Jan Beulich wrote: >> On 12.10.16 at 16:58, wrote: On 10/12/16 05:32 -0600, Jan Beulich wrote: On 12.10.16 at 12:33, wrote: >> The layout is shown as

[PATCH] Don't touch single threaded PTEs which are on the right node

From: Andi Kleen We had some problems with pages getting unmapped in single threaded affinitized processes. It was tracked down to NUMA scanning. In this case it doesn't make any sense to unmap pages if the process is single threaded and the page is already on the node the

Re: linux.git: printk() problem

On Wed, 2016-10-12 at 08:47 -0700, Linus Torvalds wrote: < We'll see. But the other issues are easily fixed by just adding > KERN_CONT where appropriate. It was actually very much what you were > supposed to do before too, if only as a marker to others that "yes, > I'm actually doing this, and no,

[PATCH] Don't touch single threaded PTEs which are on the right node

From: Andi Kleen We had some problems with pages getting unmapped in single threaded affinitized processes. It was tracked down to NUMA scanning. In this case it doesn't make any sense to unmap pages if the process is single threaded and the page is already on the node the process is running

Re: linux.git: printk() problem

On Wed, 2016-10-12 at 08:47 -0700, Linus Torvalds wrote: < We'll see. But the other issues are easily fixed by just adding > KERN_CONT where appropriate. It was actually very much what you were > supposed to do before too, if only as a marker to others that "yes, > I'm actually doing this, and no,

Re: [PATCH] mm: kmemleak: Ensure that the task stack is not freed during scanning

On Wed, Oct 12, 2016 at 11:54:17AM -0400, CAI Qian wrote: > - Original Message - > > From: "Catalin Marinas" > > To: linux...@kvack.org > > Cc: linux-kernel@vger.kernel.org, "Andrew Morton" > > , "Andy Lutomirski" , > >

Re: [PATCH] mm: kmemleak: Ensure that the task stack is not freed during scanning

On Wed, Oct 12, 2016 at 11:54:17AM -0400, CAI Qian wrote: > - Original Message - > > From: "Catalin Marinas" > > To: linux...@kvack.org > > Cc: linux-kernel@vger.kernel.org, "Andrew Morton" > > , "Andy Lutomirski" , > > "CAI Qian" > > Sent: Wednesday, October 12, 2016 5:57:03 AM > >

Re: [RFC v3 3/3] phy,leds: add support for led triggers on phy link state change

On Mon, Oct 10, 2016 at 02:03:32AM -0700, Florian Fainelli wrote: > > + > > +#ifdef CONFIG_LED_TRIGGER_PHY > > + > > +#include > > +#include > > + > > +#define PHY_LINK_LED_MAX_TRIGGERS 5 > > +#define PHY_LED_TRIGGER_SPEED_SUFFIX_SIZE 7 > > +#define PHY_MII_BUS_ID_SIZE(20 - 3) > >

Re: [RFC v3 3/3] phy,leds: add support for led triggers on phy link state change

On Mon, Oct 10, 2016 at 02:03:32AM -0700, Florian Fainelli wrote: > > + > > +#ifdef CONFIG_LED_TRIGGER_PHY > > + > > +#include > > +#include > > + > > +#define PHY_LINK_LED_MAX_TRIGGERS 5 > > +#define PHY_LED_TRIGGER_SPEED_SUFFIX_SIZE 7 > > +#define PHY_MII_BUS_ID_SIZE(20 - 3) > >

Re: linux.git: printk() problem

On Wed, 2016-10-12 at 16:35 +0200, Michal Hocko wrote: > On Wed 12-10-16 22:30:03, Tetsuo Handa wrote: > > Hello. > > > > I noticed that current linux.git generates hardly readable console output > > due to KERN_CONT changes. Are you suggesting developers that output like > > this be fixed? > >

Re: linux.git: printk() problem

On Wed, 2016-10-12 at 16:35 +0200, Michal Hocko wrote: > On Wed 12-10-16 22:30:03, Tetsuo Handa wrote: > > Hello. > > > > I noticed that current linux.git generates hardly readable console output > > due to KERN_CONT changes. Are you suggesting developers that output like > > this be fixed? > >

[PATCH v3 03/20] remoteproc: core: Add function to amend an existing resource table entry

From: Lee Jones Sometimes the firmware does not know best. When a firmware is built, it can be loaded with a resource table, usually detailing shared; memory, virtual device, trace log information etc. However, some vendors require this hard-coded information to be amended

[PATCH v3 03/20] remoteproc: core: Add function to amend an existing resource table entry

From: Lee Jones Sometimes the firmware does not know best. When a firmware is built, it can be loaded with a resource table, usually detailing shared; memory, virtual device, trace log information etc. However, some vendors require this hard-coded information to be amended with new/improved

[PATCH v3 00/20] remoteproc: Allow platform-specific drivers to request resources

Once this patch-set has been applied; platform-specific remoteproc drivers will be able to amend existing resource table entries, provide new entries to be appended to an existing resource table (if one already exists), start a new resource table (if one does not already exist), and dump out

[PATCH v3 20/20] remoteproc: core: Support empty resource tables

From: Lee Jones Currently, when a remote processor does not require resources, the platform-specific remoteproc driver has to create a fake resource table in order to by-pass the strict checking. But there is no hard requirement for a remote processor so require or support

[PATCH v3 07/20] remoteproc: core: Add RSC_VDEV support to rproc_request_resource

Add the possibility for platform specific driver to submit resource request related to VDEV. Signed-off-by: Loic Pallardy --- drivers/remoteproc/remoteproc_core.c | 7 +++ 1 file changed, 7 insertions(+) diff --git a/drivers/remoteproc/remoteproc_core.c

[PATCH v3 00/20] remoteproc: Allow platform-specific drivers to request resources

Once this patch-set has been applied; platform-specific remoteproc drivers will be able to amend existing resource table entries, provide new entries to be appended to an existing resource table (if one already exists), start a new resource table (if one does not already exist), and dump out

[PATCH v3 20/20] remoteproc: core: Support empty resource tables

From: Lee Jones Currently, when a remote processor does not require resources, the platform-specific remoteproc driver has to create a fake resource table in order to by-pass the strict checking. But there is no hard requirement for a remote processor so require or support shared resources.

[PATCH v3 07/20] remoteproc: core: Add RSC_VDEV support to rproc_request_resource

Add the possibility for platform specific driver to submit resource request related to VDEV. Signed-off-by: Loic Pallardy --- drivers/remoteproc/remoteproc_core.c | 7 +++ 1 file changed, 7 insertions(+) diff --git a/drivers/remoteproc/remoteproc_core.c

Re: [v2] timers: Fix usleep_range() in the context of wake_up_process()

On Mon, Oct 10, 2016 at 02:04:02PM -0700, Douglas Anderson wrote: > Users of usleep_range() expect that it will _never_ return in less time > than the minimum passed parameter. However, nothing in any of the code > ensures this. Specifically: > > usleep_range() => do_usleep_range() =>

Re: [PATCH v3 2/3] cpufreq: brcmstb-avs-cpufreq: AVS CPUfreq driver for Broadcom STB SoCs

On 11 October 2016 at 22:38, Viresh Kumar wrote: > On 07-10-16, 16:21, Markus Mayer wrote: >> +static int brcm_avs_cpufreq_exit(struct cpufreq_policy *policy) >> +{ >> + struct private_data *priv = policy->driver_data; >> + >> + iounmap(priv->base); >> +

Re: [PATCH v3 2/3] cpufreq: brcmstb-avs-cpufreq: AVS CPUfreq driver for Broadcom STB SoCs

On 11 October 2016 at 22:38, Viresh Kumar wrote: > On 07-10-16, 16:21, Markus Mayer wrote: >> +static int brcm_avs_cpufreq_exit(struct cpufreq_policy *policy) >> +{ >> + struct private_data *priv = policy->driver_data; >> + >> + iounmap(priv->base); >> + iounmap(priv->avs_intr_base);

Re: [v2] timers: Fix usleep_range() in the context of wake_up_process()

On Mon, Oct 10, 2016 at 02:04:02PM -0700, Douglas Anderson wrote: > Users of usleep_range() expect that it will _never_ return in less time > than the minimum passed parameter. However, nothing in any of the code > ensures this. Specifically: > > usleep_range() => do_usleep_range() =>

[PATCH v3 02/20] remoteproc: core: Add function to dump resource table

Firmware can be loaded with a resource table, which details resources needed by coprocessor like carevout memory, virtual device, trace log buffer etc. Until now, no method exists to display resource table content. This function adds the capability to display the different resources associated to

[PATCH v3 02/20] remoteproc: core: Add function to dump resource table

Firmware can be loaded with a resource table, which details resources needed by coprocessor like carevout memory, virtual device, trace log buffer etc. Until now, no method exists to display resource table content. This function adds the capability to display the different resources associated to

[PATCH v3 01/20] remoteproc: core: New API to add new resources to the resource table

From: Lee Jones In order to amend or add a new resource table entry we need a method for a platform-specific to submit them. rproc_request_resource() is a new public API which provides this functionality. It is to be called between rproc_alloc() and rproc_add().

[PATCH v3 1/2] Add OV5647 device tree documentation

Signed-off-by: Ramiro Oliveira --- .../devicetree/bindings/media/i2c/ov5647.txt | 19 +++ 1 file changed, 19 insertions(+) create mode 100644 Documentation/devicetree/bindings/media/i2c/ov5647.txt diff --git

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