Re: [RFC PATCH v2 3/3] pmbus: Add MAX31785 driver

On Thu, Jul 20, 2017 at 12:35:09AM +0930, Joel Stanley wrote: > On Tue, Jul 18, 2017 at 1:06 PM, Andrew Jeffery wrote: > > The driver features fan control and basic dual-tachometer support. > > Say something about the hardware? > > max31785 is a fancy fan controller with temp

Re: [RFC PATCH v2 3/3] pmbus: Add MAX31785 driver

On Thu, Jul 20, 2017 at 12:35:09AM +0930, Joel Stanley wrote: > On Tue, Jul 18, 2017 at 1:06 PM, Andrew Jeffery wrote: > > The driver features fan control and basic dual-tachometer support. > > Say something about the hardware? > > max31785 is a fancy fan controller with temp measurement, pwm,

RE: [PATCH 3/3] ghes_edac: add platform check to enable ghes_edac

>> Later when GHES gives you a NODE/CARD/MODULE) in an error record. You need >> to match these up. But SMBIOS only gave you two strings "Locator" and "Bank >> Locator" which have no defined syntax. You are at the mercy of the BIOS >> writer >> to put in something parseable. > > Well, at some

RE: [PATCH 3/3] ghes_edac: add platform check to enable ghes_edac

>> Later when GHES gives you a NODE/CARD/MODULE) in an error record. You need >> to match these up. But SMBIOS only gave you two strings "Locator" and "Bank >> Locator" which have no defined syntax. You are at the mercy of the BIOS >> writer >> to put in something parseable. > > Well, at some

Re: [PATCH v2 1/3] mux: Add mux_control_get_optional() API

Quoting Peter Rosin (2017-07-19 00:15:38) > On 2017-07-19 04:08, Stephen Boyd wrote: > > Quoting Peter Rosin (2017-07-17 01:20:14) > >> On 2017-07-14 23:40, Stephen Boyd wrote: > >>> @@ -441,6 +447,8 @@ struct mux_control *mux_control_get(struct device > >>> *dev, const char *mux_name) > >>>

Re: [PATCH v2 1/3] mux: Add mux_control_get_optional() API

Quoting Peter Rosin (2017-07-19 00:15:38) > On 2017-07-19 04:08, Stephen Boyd wrote: > > Quoting Peter Rosin (2017-07-17 01:20:14) > >> On 2017-07-14 23:40, Stephen Boyd wrote: > >>> @@ -441,6 +447,8 @@ struct mux_control *mux_control_get(struct device > >>> *dev, const char *mux_name) > >>>

[PATCH 2/3] arm/syscalls: Optimize work flags assembly check

Remove the double branch and use tsteq instead. Suggested-by: Russell King Signed-off-by: Thomas Garnier --- arch/arm/kernel/entry-common.S | 7 ++- 1 file changed, 2 insertions(+), 5 deletions(-) diff --git a/arch/arm/kernel/entry-common.S

[PATCH 2/3] arm/syscalls: Optimize work flags assembly check

Remove the double branch and use tsteq instead. Suggested-by: Russell King Signed-off-by: Thomas Garnier --- arch/arm/kernel/entry-common.S | 7 ++- 1 file changed, 2 insertions(+), 5 deletions(-) diff --git a/arch/arm/kernel/entry-common.S b/arch/arm/kernel/entry-common.S index

[PATCH 1/3] arm/syscalls: Move address limit check in loop

The work pending loop can call set_fs after addr_limit_user_check removed the _TIF_FSCHECK flag. To prevent the infinite loop, move the addr_limit_user_check call at the beginning of the loop. Fixes: 73ac5d6a2b6a ("arm/syscalls: Check address limit on user-mode return") Reported-by: Leonard

[PATCH 1/3] arm/syscalls: Move address limit check in loop

The work pending loop can call set_fs after addr_limit_user_check removed the _TIF_FSCHECK flag. To prevent the infinite loop, move the addr_limit_user_check call at the beginning of the loop. Fixes: 73ac5d6a2b6a ("arm/syscalls: Check address limit on user-mode return") Reported-by: Leonard

[PATCH 3/3] arm64/syscalls: Move address limit check in loop

The original bug was reported on arm but I am fixing arm64 too because it has a similar code pattern. The work pending loop can call set_fs after addr_limit_user_check removed the _TIF_FSCHECK flag. To prevent the infinite loop, move the addr_limit_user_check call at the beginning of the loop.

Re: [PATCH] netvsc: Remove redundant use of ipv6_hdr()

On Wed, 19 Jul 2017 13:48:03 -0400 (EDT) Mohammed Gamal wrote: > - Original Message - > > On Wed, 19 Jul 2017 15:19:28 +0200 > > Mohammed Gamal wrote: > > > > > This condition already uses an object of type ipv6hdr in the line above. > > > Use

[PATCH 3/3] arm64/syscalls: Move address limit check in loop

The original bug was reported on arm but I am fixing arm64 too because it has a similar code pattern. The work pending loop can call set_fs after addr_limit_user_check removed the _TIF_FSCHECK flag. To prevent the infinite loop, move the addr_limit_user_check call at the beginning of the loop.

Re: [PATCH] netvsc: Remove redundant use of ipv6_hdr()

On Wed, 19 Jul 2017 13:48:03 -0400 (EDT) Mohammed Gamal wrote: > - Original Message - > > On Wed, 19 Jul 2017 15:19:28 +0200 > > Mohammed Gamal wrote: > > > > > This condition already uses an object of type ipv6hdr in the line above. > > > Use the object directly instead of calling

Re: [PATCH v4 3/3] KVM: nVMX: Emulate EPTP switching for the L1 hypervisor

Radim Krčmář writes: > 2017-07-17 13:58-0400, Bandan Das: >> Radim Krčmář writes: >> ... > and no other mentions of a VM exit, so I think that the VM exit happens > only under these conditions: > > — The EPT memory type (bits 2:0)

Re: [PATCH v4 3/3] KVM: nVMX: Emulate EPTP switching for the L1 hypervisor

Radim Krčmář writes: > 2017-07-17 13:58-0400, Bandan Das: >> Radim Krčmář writes: >> ... > and no other mentions of a VM exit, so I think that the VM exit happens > only under these conditions: > > — The EPT memory type (bits 2:0) must be a value supported by the >

Re: [PATCH] libkmod-elf: resolve CRC if module is built with MODULE_REL_CRCS

On Wed, Jul 19, 2017 at 7:56 AM, Yauheni Kaliuta wrote: > Normally exported symbol's crc is stored as absolute (SHN_ABS) > value of special named symbol __crc_. > > When the kernel and modules are built with the config option > CONFIG_MODULE_REL_CRCS, all the CRCs are

Re: [PATCH] libkmod-elf: resolve CRC if module is built with MODULE_REL_CRCS

On Wed, Jul 19, 2017 at 7:56 AM, Yauheni Kaliuta wrote: > Normally exported symbol's crc is stored as absolute (SHN_ABS) > value of special named symbol __crc_. > > When the kernel and modules are built with the config option > CONFIG_MODULE_REL_CRCS, all the CRCs are put in a special section >

Re: [PATCH v3 1/5] mm: add vm_insert_mixed_mkwrite()

On Wed, Jul 19, 2017 at 04:16:59PM +0200, Jan Kara wrote: > On Wed 28-06-17 16:01:48, Ross Zwisler wrote: > > To be able to use the common 4k zero page in DAX we need to have our PTE > > fault path look more like our PMD fault path where a PTE entry can be > > marked as dirty and writeable as it

Re: [PATCH v3 1/5] mm: add vm_insert_mixed_mkwrite()

On Wed, Jul 19, 2017 at 04:16:59PM +0200, Jan Kara wrote: > On Wed 28-06-17 16:01:48, Ross Zwisler wrote: > > To be able to use the common 4k zero page in DAX we need to have our PTE > > fault path look more like our PMD fault path where a PTE entry can be > > marked as dirty and writeable as it

Re: [PATCH 5/6] cgroup: implement cgroup v2 thread support

Hello, Waiman. On Wed, Jul 19, 2017 at 01:09:38PM -0400, Waiman Long wrote: > For me, that is the only good reason why we should keep the current > behavior. So I am fine with that. > > + cgrp->dom_cgrp = cgrp->dom_cgrp; > > However, I am still puzzled by above line of code, should it be just >

Re: [PATCH 5/6] cgroup: implement cgroup v2 thread support

Hello, Waiman. On Wed, Jul 19, 2017 at 01:09:38PM -0400, Waiman Long wrote: > For me, that is the only good reason why we should keep the current > behavior. So I am fine with that. > > + cgrp->dom_cgrp = cgrp->dom_cgrp; > > However, I am still puzzled by above line of code, should it be just >

Re: [PATCH] rtc: sun6i: ensure clk_data is kfree'd on error

On 19/07/17 18:32, Alexandre Belloni wrote: > Hi, > > On 19/07/2017 at 17:57:02 +0100, Colin King wrote: >> From: Colin Ian King >> >> There are two error return paths that do not kfree clk_data and >> we end up with a memory leak. Fix these with a kfree error exit >>

Re: [PATCH] rtc: sun6i: ensure clk_data is kfree'd on error

On 19/07/17 18:32, Alexandre Belloni wrote: > Hi, > > On 19/07/2017 at 17:57:02 +0100, Colin King wrote: >> From: Colin Ian King >> >> There are two error return paths that do not kfree clk_data and >> we end up with a memory leak. Fix these with a kfree error exit >> path. >> >> Detected by

Re: [PATCH] netvsc: Remove redundant use of ipv6_hdr()

- Original Message - > On Wed, 19 Jul 2017 15:19:28 +0200 > Mohammed Gamal wrote: > > > This condition already uses an object of type ipv6hdr in the line above. > > Use the object directly instead of calling ipv6_hdr > > > > Signed-off-by: Mohammed Gamal

Re: [PATCH] netvsc: Remove redundant use of ipv6_hdr()

- Original Message - > On Wed, 19 Jul 2017 15:19:28 +0200 > Mohammed Gamal wrote: > > > This condition already uses an object of type ipv6hdr in the line above. > > Use the object directly instead of calling ipv6_hdr > > > > Signed-off-by: Mohammed Gamal > > --- > >

[PATCH] net: tehuti: don't process data if it has not been copied from userspace

From: Colin Ian King The array data is only populated with valid information from userspace if cmd != SIOCDEVPRIVATE, other cases the array contains garbage on the stack. The subsequent switch statement acts on a subcommand in data[0] which could be any garbage value if

[PATCH] net: tehuti: don't process data if it has not been copied from userspace

From: Colin Ian King The array data is only populated with valid information from userspace if cmd != SIOCDEVPRIVATE, other cases the array contains garbage on the stack. The subsequent switch statement acts on a subcommand in data[0] which could be any garbage value if cmd is SIOCDEVPRIVATE

Re: [PATCH] Revert "x86/uaccess: Add stack frame output operand in get_user() inline asm"

On Thu, Jul 13, 2017 at 02:57:04PM -0700, Matthias Kaehlcke wrote: > El Thu, Jul 13, 2017 at 04:34:06PM -0500 Josh Poimboeuf ha dit: > > > On Thu, Jul 13, 2017 at 02:12:45PM -0700, Matthias Kaehlcke wrote: > > > El Thu, Jul 13, 2017 at 03:34:16PM -0500 Josh Poimboeuf ha dit: > > > > And yet

Re: [PATCH] Revert "x86/uaccess: Add stack frame output operand in get_user() inline asm"

On Thu, Jul 13, 2017 at 02:57:04PM -0700, Matthias Kaehlcke wrote: > El Thu, Jul 13, 2017 at 04:34:06PM -0500 Josh Poimboeuf ha dit: > > > On Thu, Jul 13, 2017 at 02:12:45PM -0700, Matthias Kaehlcke wrote: > > > El Thu, Jul 13, 2017 at 03:34:16PM -0500 Josh Poimboeuf ha dit: > > > > And yet

Re: [PATCH] documentation: Fix two-CPU control-dependency example

On Mon, Jul 17, 2017 at 05:24:42PM +0900, Akira Yokosawa wrote: > >From b798b9b631e237d285aa8699da00bfb8ced33bea Mon Sep 17 00:00:00 2001 > From: Akira Yokosawa > Date: Mon, 17 Jul 2017 16:25:33 +0900 > Subject: [PATCH] documentation: Fix two-CPU control-dependency example > >

Re: [PATCH] documentation: Fix two-CPU control-dependency example

On Mon, Jul 17, 2017 at 05:24:42PM +0900, Akira Yokosawa wrote: > >From b798b9b631e237d285aa8699da00bfb8ced33bea Mon Sep 17 00:00:00 2001 > From: Akira Yokosawa > Date: Mon, 17 Jul 2017 16:25:33 +0900 > Subject: [PATCH] documentation: Fix two-CPU control-dependency example > > In commit

[PATCH 2/3] livepatch: add atomic replace

When doing cumulative patches, if patch A introduces a change to function 1, and patch B reverts the change to function 1 and introduces changes to say function 2 and 3 as well, the change that patch A introduced to function 1 is still present. Introduce atomic replace, by first creating a

[PATCH 2/3] livepatch: add atomic replace

When doing cumulative patches, if patch A introduces a change to function 1, and patch B reverts the change to function 1 and introduces changes to say function 2 and 3 as well, the change that patch A introduced to function 1 is still present. Introduce atomic replace, by first creating a

Re: [PATCH] c6x: Convert to using %pOF instead of full_name

On Tue, 2017-07-18 at 16:42 -0500, Rob Herring wrote: > Now that we have a custom printf format specifier, convert users of > full_name to use %pOF instead. This is preparation to remove storing > of the full path string for each node. > > Signed-off-by: Rob Herring > Cc: Mark

Re: [PATCH] c6x: Convert to using %pOF instead of full_name

On Tue, 2017-07-18 at 16:42 -0500, Rob Herring wrote: > Now that we have a custom printf format specifier, convert users of > full_name to use %pOF instead. This is preparation to remove storing > of the full path string for each node. > > Signed-off-by: Rob Herring > Cc: Mark Salter > Cc:

[PATCH] drm/i915: Pass enum pipe to intel_set_pch_fifo_underrun_reporting()

Commit a21960339c8c ("drm/i915: Consistently use enum pipe for PCH transcoders") misses some pieces, due to a problem with the patch format, this patch adds the remaining bits. Fixes: a21960339c8c ("drm/i915: Consistently use enum pipe for PCH transcoders") Signed-off-by: Matthias Kaehlcke

[PATCH] drm/i915: Pass enum pipe to intel_set_pch_fifo_underrun_reporting()

Commit a21960339c8c ("drm/i915: Consistently use enum pipe for PCH transcoders") misses some pieces, due to a problem with the patch format, this patch adds the remaining bits. Fixes: a21960339c8c ("drm/i915: Consistently use enum pipe for PCH transcoders") Signed-off-by: Matthias Kaehlcke ---

[PATCH] fs: convert sync_file_range to use errseq_t based error-tracking

From: Jeff Layton sync_file_range doesn't call down into the filesystem directly at all. It only kicks off writeback of pagecache pages and optionally waits on the result. Convert sync_file_range to use errseq_t based error tracking, under the assumption that most users will

[PATCH] fs: convert sync_file_range to use errseq_t based error-tracking

From: Jeff Layton sync_file_range doesn't call down into the filesystem directly at all. It only kicks off writeback of pagecache pages and optionally waits on the result. Convert sync_file_range to use errseq_t based error tracking, under the assumption that most users will prefer this

Re: [PATCH 095/102] watchdog: rt2880: explicitly request exclusive reset control

On Wed, Jul 19, 2017 at 05:26:39PM +0200, Philipp Zabel wrote: > Commit a53e35db70d1 ("reset: Ensure drivers are explicit when requesting > reset lines") started to transition the reset control request API calls > to explicitly state whether the driver needs exclusive or shared reset > control

Re: [PATCH 096/102] watchdog: zx2967: explicitly request exclusive reset control

On Wed, Jul 19, 2017 at 05:26:40PM +0200, Philipp Zabel wrote: > Commit a53e35db70d1 ("reset: Ensure drivers are explicit when requesting > reset lines") started to transition the reset control request API calls > to explicitly state whether the driver needs exclusive or shared reset > control

Re: [PATCH 095/102] watchdog: rt2880: explicitly request exclusive reset control

On Wed, Jul 19, 2017 at 05:26:39PM +0200, Philipp Zabel wrote: > Commit a53e35db70d1 ("reset: Ensure drivers are explicit when requesting > reset lines") started to transition the reset control request API calls > to explicitly state whether the driver needs exclusive or shared reset > control

Re: [PATCH 096/102] watchdog: zx2967: explicitly request exclusive reset control

On Wed, Jul 19, 2017 at 05:26:40PM +0200, Philipp Zabel wrote: > Commit a53e35db70d1 ("reset: Ensure drivers are explicit when requesting > reset lines") started to transition the reset control request API calls > to explicitly state whether the driver needs exclusive or shared reset > control

Re: [PATCH 094/102] watchdog: mt7621: explicitly request exclusive reset control

On Wed, Jul 19, 2017 at 05:26:38PM +0200, Philipp Zabel wrote: > Commit a53e35db70d1 ("reset: Ensure drivers are explicit when requesting > reset lines") started to transition the reset control request API calls > to explicitly state whether the driver needs exclusive or shared reset > control

Re: [PATCH 094/102] watchdog: mt7621: explicitly request exclusive reset control

On Wed, Jul 19, 2017 at 05:26:38PM +0200, Philipp Zabel wrote: > Commit a53e35db70d1 ("reset: Ensure drivers are explicit when requesting > reset lines") started to transition the reset control request API calls > to explicitly state whether the driver needs exclusive or shared reset > control

Re: [PATCH 093/102] watchdog: asm9260: explicitly request exclusive reset control

On Wed, Jul 19, 2017 at 05:26:37PM +0200, Philipp Zabel wrote: > Commit a53e35db70d1 ("reset: Ensure drivers are explicit when requesting > reset lines") started to transition the reset control request API calls > to explicitly state whether the driver needs exclusive or shared reset > control

Re: [PATCH 093/102] watchdog: asm9260: explicitly request exclusive reset control

On Wed, Jul 19, 2017 at 05:26:37PM +0200, Philipp Zabel wrote: > Commit a53e35db70d1 ("reset: Ensure drivers are explicit when requesting > reset lines") started to transition the reset control request API calls > to explicitly state whether the driver needs exclusive or shared reset > control

Re: [PATCH v2 9/9] perf annotate: Use the sample period when calculating the percentage

On 07/19/2017 01:23 AM, Namhyung Kim wrote: On Fri, Jul 14, 2017 at 02:46:20AM +0900, Taeung Song wrote: Currently the percentages of perf-annotate are calculated with number of samples, not the sample period. So fix it to correspond with perf-report using the sample period for the

Re: [PATCH v2 9/9] perf annotate: Use the sample period when calculating the percentage

On 07/19/2017 01:23 AM, Namhyung Kim wrote: On Fri, Jul 14, 2017 at 02:46:20AM +0900, Taeung Song wrote: Currently the percentages of perf-annotate are calculated with number of samples, not the sample period. So fix it to correspond with perf-report using the sample period for the

[PATCH 0/3] livepatch: introduce atomic replace

Hi, In testing livepatch, I found that when doing cumulative patches, if a patched function is completed reverted by a subsequent patch (back to its original state) livepatch does not revert the funtion to its original state. Specifically, if patch A introduces a change to function 1, and patch

[PATCH 0/3] livepatch: introduce atomic replace

Hi, In testing livepatch, I found that when doing cumulative patches, if a patched function is completed reverted by a subsequent patch (back to its original state) livepatch does not revert the funtion to its original state. Specifically, if patch A introduces a change to function 1, and patch

[PATCH 3/3] livepatch: Add a sysctl livepatch_mode for atomic replace

Introduce a sysctl knob such that by default livepatch is not in 'atomic replace' mode. A '0' in /proc/sys/kernel/livepatch_mode means the current default mode, while a '1' means do atomic replace. Signed-off-by: Jason Baron Cc: Josh Poimboeuf Cc: Jessica

[PATCH 3/3] livepatch: Add a sysctl livepatch_mode for atomic replace

Introduce a sysctl knob such that by default livepatch is not in 'atomic replace' mode. A '0' in /proc/sys/kernel/livepatch_mode means the current default mode, while a '1' means do atomic replace. Signed-off-by: Jason Baron Cc: Josh Poimboeuf Cc: Jessica Yu Cc: Jiri Kosina Cc: Miroslav Benes

Re: [PATCH] rtc: sun6i: ensure clk_data is kfree'd on error

Hi, On 19/07/2017 at 17:57:02 +0100, Colin King wrote: > From: Colin Ian King > > There are two error return paths that do not kfree clk_data and > we end up with a memory leak. Fix these with a kfree error exit > path. > > Detected by CoverityScan, CID#1402959

Re: [PATCH] rtc: sun6i: ensure clk_data is kfree'd on error

Hi, On 19/07/2017 at 17:57:02 +0100, Colin King wrote: > From: Colin Ian King > > There are two error return paths that do not kfree clk_data and > we end up with a memory leak. Fix these with a kfree error exit > path. > > Detected by CoverityScan, CID#1402959 ("Resource Leak") > I think

Re: [PATCH 7/7] staging: fsl-mc: allow the driver compile multi-arch

Hi Laurentiu, [auto build test ERROR on staging/staging-testing] [also build test ERROR on v4.13-rc1 next-20170718] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url:

Re: [PATCH 7/7] staging: fsl-mc: allow the driver compile multi-arch

Hi Laurentiu, [auto build test ERROR on staging/staging-testing] [also build test ERROR on v4.13-rc1 next-20170718] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url:

[PATCH 1/3] livepatch: Add klp_object and klp_func iterators

In preparation to introducing atomic replace, introduce iterators for klp_func and klp_object, such that objects and functions can be dynmically allocated (needed for atomic replace). Note that this patch is careful, not to grow the size of klp_func as that's the most common data structure. This

[PATCH 1/3] livepatch: Add klp_object and klp_func iterators

In preparation to introducing atomic replace, introduce iterators for klp_func and klp_object, such that objects and functions can be dynmically allocated (needed for atomic replace). Note that this patch is careful, not to grow the size of klp_func as that's the most common data structure. This

Re: [PATCH v2 1/2] video/hdmi: Introduce helpers for the HDMI audio infoframe payload

Hi On Tue, Jul 18, 2017 at 5:49 PM, Chris Zhong wrote: > Hi Doug > > > > On Tuesday, July 18, 2017 11:16 PM, Doug Anderson wrote: >> >> Hi, >> >> On Tue, Jul 18, 2017 at 4:20 AM, Chris Zhong wrote: >>> >>> The DP is using the same audio infoframe

Re: [PATCH v2 1/2] video/hdmi: Introduce helpers for the HDMI audio infoframe payload

Hi On Tue, Jul 18, 2017 at 5:49 PM, Chris Zhong wrote: > Hi Doug > > > > On Tuesday, July 18, 2017 11:16 PM, Doug Anderson wrote: >> >> Hi, >> >> On Tue, Jul 18, 2017 at 4:20 AM, Chris Zhong wrote: >>> >>> The DP is using the same audio infoframe payload as hdmi, per DP 1.3 >>> spec, but it has

[PATCH] drm: disable vblank only if it got previously enabled

mimic the behavior of vblank_disable_fn(), another caller of drm_vblank_disable_and_save(). This avoids oopsing, while trying to disable vblank on a not connected display: [ 12.768079] WARNING: CPU: 0 PID: 274 at drivers/gpu/drm/drm_vblank.c:609

[PATCH] drm: disable vblank only if it got previously enabled

mimic the behavior of vblank_disable_fn(), another caller of drm_vblank_disable_and_save(). This avoids oopsing, while trying to disable vblank on a not connected display: [ 12.768079] WARNING: CPU: 0 PID: 274 at drivers/gpu/drm/drm_vblank.c:609

Re: [RFC PATCH v12 3/4] Linux Random Number Generator

On Wed, Jul 19, 2017 at 08:22:18AM +0200, Stephan Müller wrote: > In the email [1] I have expressed the core concerns I see -- none of them > address the need to keep the Jitter RNG as one noise source. To address > those, > a very deep dive into random.c needs to be made. That's simply not

Re: [RFC PATCH v12 3/4] Linux Random Number Generator

On Wed, Jul 19, 2017 at 08:22:18AM +0200, Stephan Müller wrote: > In the email [1] I have expressed the core concerns I see -- none of them > address the need to keep the Jitter RNG as one noise source. To address > those, > a very deep dive into random.c needs to be made. That's simply not

[PATCH 0/1] acpi: apei: Enable APEI multiple GHES source to share an single external IRQ

Rafael, What do you think of this one? I was submitted a long time ago but there was never any real resolution to it. Loc Ho (1): acpi: apei: Enable APEI multiple GHES source to share an single external IRQ drivers/acpi/apei/ghes.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)

[PATCH 0/1] acpi: apei: Enable APEI multiple GHES source to share an single external IRQ

Rafael, What do you think of this one? I was submitted a long time ago but there was never any real resolution to it. Loc Ho (1): acpi: apei: Enable APEI multiple GHES source to share an single external IRQ drivers/acpi/apei/ghes.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)

[PATCH 1/1] acpi: apei: Enable APEI multiple GHES source to share an single external IRQ

From: Loc Ho This patch allows APEI generic error source table with external IRQ to share an single IRQ. Signed-off-by: Tuan Phan Signed-off-by: Loc Ho Signed-off-by: Mark Salter --- drivers/acpi/apei/ghes.c | 3 ++- 1 file

[PATCH 1/1] acpi: apei: Enable APEI multiple GHES source to share an single external IRQ

From: Loc Ho This patch allows APEI generic error source table with external IRQ to share an single IRQ. Signed-off-by: Tuan Phan Signed-off-by: Loc Ho Signed-off-by: Mark Salter --- drivers/acpi/apei/ghes.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git

Re: [kernel-hardening] Re: [PATCH v10 2/3] arm/syscalls: Check address limit on user-mode return

On Wed, Jul 19, 2017 at 10:06 AM, Russell King - ARM Linux wrote: > On Wed, Jul 19, 2017 at 05:58:20PM +0300, Leonard Crestez wrote: >> On Tue, 2017-07-18 at 12:04 -0700, Thomas Garnier wrote: >> > On Tue, Jul 18, 2017 at 10:18 AM, Leonard Crestez >> >

Re: [kernel-hardening] Re: [PATCH v10 2/3] arm/syscalls: Check address limit on user-mode return

On Wed, Jul 19, 2017 at 10:06 AM, Russell King - ARM Linux wrote: > On Wed, Jul 19, 2017 at 05:58:20PM +0300, Leonard Crestez wrote: >> On Tue, 2017-07-18 at 12:04 -0700, Thomas Garnier wrote: >> > On Tue, Jul 18, 2017 at 10:18 AM, Leonard Crestez >> > wrote: >> > > On Tue, 2017-07-18 at 09:04

Re: [PATCH v2] xen: xen-pciback: remove DRIVER_ATTR() usage

On 19/07/17 17:17, Greg KH wrote: > On Wed, Jul 19, 2017 at 04:51:02PM +0200, Juergen Gross wrote: >> On 19/07/17 16:43, Greg KH wrote: >>> From: Greg Kroah-Hartman >>> >>> It's better to be explicit and use the DRIVER_ATTR_RW() and >>> DRIVER_ATTR_RO() macros when

Re: [PATCH v2] xen: xen-pciback: remove DRIVER_ATTR() usage

On 19/07/17 17:17, Greg KH wrote: > On Wed, Jul 19, 2017 at 04:51:02PM +0200, Juergen Gross wrote: >> On 19/07/17 16:43, Greg KH wrote: >>> From: Greg Kroah-Hartman >>> >>> It's better to be explicit and use the DRIVER_ATTR_RW() and >>> DRIVER_ATTR_RO() macros when defining a driver's sysfs file.

Re: [PATCH v2 8/9] perf annotate browser: Support the toggle number of samples with a 'e' hotkey

On 07/19/2017 01:18 AM, Namhyung Kim wrote: On Fri, Jul 14, 2017 at 02:46:16AM +0900, Taeung Song wrote: Cc: Namhyung Kim Cc: Milian Wolff Cc: Jiri Olsa Signed-off-by: Taeung Song Hmm.. IIUC there're

Re: [PATCH v2 8/9] perf annotate browser: Support the toggle number of samples with a 'e' hotkey

On 07/19/2017 01:18 AM, Namhyung Kim wrote: On Fri, Jul 14, 2017 at 02:46:16AM +0900, Taeung Song wrote: Cc: Namhyung Kim Cc: Milian Wolff Cc: Jiri Olsa Signed-off-by: Taeung Song Hmm.. IIUC there're 3 modes of annotation view: percent, period and sample, right? The existing 't' hotkey

Re: [PATCH 5/6] cgroup: implement cgroup v2 thread support

On 07/19/2017 12:29 PM, Tejun Heo wrote: > Hello, > > On Tue, Jul 18, 2017 at 01:23:14PM -0400, Waiman Long wrote: >>> If we could get rid of the invalid state completely that way, I'd >>> completely agree with you but that isn't the case here as you noted >>> yourself, so the choice between the

Re: [PATCH 5/6] cgroup: implement cgroup v2 thread support

On 07/19/2017 12:29 PM, Tejun Heo wrote: > Hello, > > On Tue, Jul 18, 2017 at 01:23:14PM -0400, Waiman Long wrote: >>> If we could get rid of the invalid state completely that way, I'd >>> completely agree with you but that isn't the case here as you noted >>> yourself, so the choice between the

Re: [PATCH v10 2/3] arm/syscalls: Check address limit on user-mode return

On Wed, Jul 19, 2017 at 05:58:20PM +0300, Leonard Crestez wrote: > On Tue, 2017-07-18 at 12:04 -0700, Thomas Garnier wrote: > > On Tue, Jul 18, 2017 at 10:18 AM, Leonard Crestez > > wrote: > > > On Tue, 2017-07-18 at 09:04 -0700, Thomas Garnier wrote: > > > > On Tue, Jul

Re: [PATCH v10 2/3] arm/syscalls: Check address limit on user-mode return

On Wed, Jul 19, 2017 at 05:58:20PM +0300, Leonard Crestez wrote: > On Tue, 2017-07-18 at 12:04 -0700, Thomas Garnier wrote: > > On Tue, Jul 18, 2017 at 10:18 AM, Leonard Crestez > > wrote: > > > On Tue, 2017-07-18 at 09:04 -0700, Thomas Garnier wrote: > > > > On Tue, Jul 18, 2017 at 7:36 AM,

[PATCH 2/2] arm64: dts: move rpi into rpi directory

Place rpi into its own subdirectory. This helps as the number of Broadcom boards grow and we can separate them per SoC. Signed-off-by: Scott Branden --- arch/arm64/boot/dts/broadcom/Makefile | 3 +-- arch/arm64/boot/dts/broadcom/bcm2835-rpi.dtsi

[PATCH 2/2] arm64: dts: move rpi into rpi directory

Place rpi into its own subdirectory. This helps as the number of Broadcom boards grow and we can separate them per SoC. Signed-off-by: Scott Branden --- arch/arm64/boot/dts/broadcom/Makefile | 3 +-- arch/arm64/boot/dts/broadcom/bcm2835-rpi.dtsi | 1 -

[PATCH 1/2] arm64: dts: move ns2 into northstar2 directory

Place northstar2 into its own subdirectory. This helps as the number of Broadcom boards grow and we can separate them per SoC. Signed-off-by: Scott Branden --- arch/arm64/boot/dts/broadcom/Makefile| 4 ++--

[PATCH 1/2] arm64: dts: move ns2 into northstar2 directory

Place northstar2 into its own subdirectory. This helps as the number of Broadcom boards grow and we can separate them per SoC. Signed-off-by: Scott Branden --- arch/arm64/boot/dts/broadcom/Makefile| 4 ++-- arch/arm64/boot/dts/broadcom/northstar2/Makefile |

[PATCH 0/2] arm64: dts: cleanup Broadcom boards per SoC

Separate Broadcom boards per SoC to assist in cleaner management of boards. This has already been done for Stingray and is done here for RPI and NS2. If this is problematic for RPI please let me know and RPI patch can be dropped from patch series. Scott Branden (2): arm64: dts: move ns2 into

[PATCH 0/2] arm64: dts: cleanup Broadcom boards per SoC

Separate Broadcom boards per SoC to assist in cleaner management of boards. This has already been done for Stingray and is done here for RPI and NS2. If this is problematic for RPI please let me know and RPI patch can be dropped from patch series. Scott Branden (2): arm64: dts: move ns2 into

[PATCH v2 1/2] power: supply: move HDQ interface for bq27xxx from w1 to power/supply

The HDQ interface driver should be in this folder just like the I2C interface driver. Move this driver out of drivers/w1/slave and into drivers/power/supply. Signed-off-by: Andrew F. Davis Acked-by: Pali Rohár Acked-by: Sebastian Reichel ---

[PATCH v2 1/2] power: supply: move HDQ interface for bq27xxx from w1 to power/supply

The HDQ interface driver should be in this folder just like the I2C interface driver. Move this driver out of drivers/w1/slave and into drivers/power/supply. Signed-off-by: Andrew F. Davis Acked-by: Pali Rohár Acked-by: Sebastian Reichel --- drivers/power/supply/Kconfig

[PATCH v2 0/2] Remove BQ27xxx platform interface

To finish the work started in this patch[0] we needed to reorganize the 1-wire subsystem a bit, this is done here[1]. After that is taken this series can remove the need for a platform driver for supporting 1-wire connected BQ27xxx devices. Thanks, Andrew Changes from v1: - Rebased on v4.13-rc1

[PATCH v2 0/2] Remove BQ27xxx platform interface

To finish the work started in this patch[0] we needed to reorganize the 1-wire subsystem a bit, this is done here[1]. After that is taken this series can remove the need for a platform driver for supporting 1-wire connected BQ27xxx devices. Thanks, Andrew Changes from v1: - Rebased on v4.13-rc1

Re: [PATCH v2 0/9] perf annotate: Fix --show-total-period and support --show-nr-samples

Hi Namhyung, I'm late. Thanks for your review. On 07/19/2017 01:07 AM, Namhyung Kim wrote: Hi Taeung, On Fri, Jul 14, 2017 at 02:45:44AM +0900, Taeung Song wrote: Hello, Currently the --show-total-period option of perf-annotate is different from perf-report's. It has two problem like

Re: [PATCH v2 0/9] perf annotate: Fix --show-total-period and support --show-nr-samples

Hi Namhyung, I'm late. Thanks for your review. On 07/19/2017 01:07 AM, Namhyung Kim wrote: Hi Taeung, On Fri, Jul 14, 2017 at 02:45:44AM +0900, Taeung Song wrote: Hello, Currently the --show-total-period option of perf-annotate is different from perf-report's. It has two problem like

[PATCH v2 2/2] power: supply: bq27xxx: move platform driver code into bq27xxx_battery_hdq.c

When the BQ27xxx driver was originally written the w1 subsystem only allowed device drivers for w1 attached devices to live in the w1 subsystem. Kernel driver subsystems expect that the driver for a device live in the directory of the subsystem for which it implements functionality, not in the

[PATCH v2 2/2] power: supply: bq27xxx: move platform driver code into bq27xxx_battery_hdq.c

When the BQ27xxx driver was originally written the w1 subsystem only allowed device drivers for w1 attached devices to live in the w1 subsystem. Kernel driver subsystems expect that the driver for a device live in the directory of the subsystem for which it implements functionality, not in the

Re: [PATCH v2 1/2] platform: Add driver for RAVE Supervisory Processor

On Tue, Jul 18, 2017 at 11:48 AM, Andy Shevchenko wrote: > On Tue, Jul 18, 2017 at 8:56 PM, Andrey Smirnov > wrote: >> Add a driver for RAVE Supervisory Processor, an MCU implementing >> varoius bits of housekeeping functionality (watchdoging,

Re: [PATCH v2 1/2] platform: Add driver for RAVE Supervisory Processor

On Tue, Jul 18, 2017 at 11:48 AM, Andy Shevchenko wrote: > On Tue, Jul 18, 2017 at 8:56 PM, Andrey Smirnov > wrote: >> Add a driver for RAVE Supervisory Processor, an MCU implementing >> varoius bits of housekeeping functionality (watchdoging, backlight >> control, LED control, etc) on RAVE

Re: [PATCH 071/102] remoteproc/keystone: explicitly request exclusive reset control

On 07/19/2017 10:26 AM, Philipp Zabel wrote: > Commit a53e35db70d1 ("reset: Ensure drivers are explicit when requesting > reset lines") started to transition the reset control request API calls > to explicitly state whether the driver needs exclusive or shared reset > control behavior. Convert all

Re: [PATCH 071/102] remoteproc/keystone: explicitly request exclusive reset control

On 07/19/2017 10:26 AM, Philipp Zabel wrote: > Commit a53e35db70d1 ("reset: Ensure drivers are explicit when requesting > reset lines") started to transition the reset control request API calls > to explicitly state whether the driver needs exclusive or shared reset > control behavior. Convert all

[PATCH] rtc: sun6i: ensure clk_data is kfree'd on error

From: Colin Ian King There are two error return paths that do not kfree clk_data and we end up with a memory leak. Fix these with a kfree error exit path. Detected by CoverityScan, CID#1402959 ("Resource Leak") Signed-off-by: Colin Ian King

[PATCH] rtc: sun6i: ensure clk_data is kfree'd on error

From: Colin Ian King There are two error return paths that do not kfree clk_data and we end up with a memory leak. Fix these with a kfree error exit path. Detected by CoverityScan, CID#1402959 ("Resource Leak") Signed-off-by: Colin Ian King --- drivers/rtc/rtc-sun6i.c | 8 ++-- 1 file

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