[patch V2 19/24] ACPI/processor: Use cpu_hotplug_disable() instead of get_online_cpus()

Converting the hotplug locking, i.e. get_online_cpus(), to a percpu rwsem unearthed a circular lock dependency which was hidden from lockdep due to the lockdep annotation of get_online_cpus() which prevents lockdep from creating full dependency chains. CPU0CPU1

[patch V2 12/24] s390/kernel: Use stop_machine_cpuslocked()

stp_work_fn() holds get_online_cpus() while invoking stop_machine(). stop_machine() invokes get_online_cpus() as well. This is correct, but prevents the conversion of the hotplug locking to a percpu rwsem. Use stop_machine_cpuslocked() to avoid the nested call. Signed-off-by: Sebastian Andrzej

[patch V2 23/24] perf: Avoid cpu_hotplug_lock r-r recursion

There are two call-sites where using static_key results in recursing on the cpu_hotplug_lock. Use the hotplug locked version of static_key_slow_inc(). Signed-off-by: Peter Zijlstra (Intel) Cc: jba...@akamai.com Cc: bige...@linutronix.de Cc: rost...@goodmis.org Link:

[patch V2 19/24] ACPI/processor: Use cpu_hotplug_disable() instead of get_online_cpus()

Converting the hotplug locking, i.e. get_online_cpus(), to a percpu rwsem unearthed a circular lock dependency which was hidden from lockdep due to the lockdep annotation of get_online_cpus() which prevents lockdep from creating full dependency chains. CPU0CPU1

[patch V2 12/24] s390/kernel: Use stop_machine_cpuslocked()

stp_work_fn() holds get_online_cpus() while invoking stop_machine(). stop_machine() invokes get_online_cpus() as well. This is correct, but prevents the conversion of the hotplug locking to a percpu rwsem. Use stop_machine_cpuslocked() to avoid the nested call. Signed-off-by: Sebastian Andrzej

[patch V2 23/24] perf: Avoid cpu_hotplug_lock r-r recursion

There are two call-sites where using static_key results in recursing on the cpu_hotplug_lock. Use the hotplug locked version of static_key_slow_inc(). Signed-off-by: Peter Zijlstra (Intel) Cc: jba...@akamai.com Cc: bige...@linutronix.de Cc: rost...@goodmis.org Link:

[patch V2 14/24] cpu/hotplug: Use stop_machine_cpuslocked() in takedown_cpu()

From: Sebastian Andrzej Siewior takedown_cpu() is a cpu hotplug function invoking stop_machine(). The cpu hotplug machinery holds the hotplug lock for write. stop_machine() invokes get_online_cpus() as well. This is correct, but prevents the conversion of the hotplug

[patch V2 10/24] perf/x86/intel/cqm: Use cpuhp_setup_state_cpuslocked()

From: Sebastian Andrzej Siewior intel_cqm_init() holds get_online_cpus() while registerring the hotplug callbacks. cpuhp_setup_state() invokes get_online_cpus() as well. This is correct, but prevents the conversion of the hotplug locking to a percpu rwsem. Use

[patch V2 09/24] hwtracing/coresight-etm4x: Use cpuhp_setup_state_nocalls_cpuslocked()

From: Sebastian Andrzej Siewior etm_probe4() holds get_online_cpus() while invoking cpuhp_setup_state_nocalls(). cpuhp_setup_state_nocalls() invokes get_online_cpus() as well. This is correct, but prevents the conversion of the hotplug locking to a percpu rwsem. Use

[patch V2 14/24] cpu/hotplug: Use stop_machine_cpuslocked() in takedown_cpu()

From: Sebastian Andrzej Siewior takedown_cpu() is a cpu hotplug function invoking stop_machine(). The cpu hotplug machinery holds the hotplug lock for write. stop_machine() invokes get_online_cpus() as well. This is correct, but prevents the conversion of the hotplug locking to a percpu rwsem.

[patch V2 10/24] perf/x86/intel/cqm: Use cpuhp_setup_state_cpuslocked()

From: Sebastian Andrzej Siewior intel_cqm_init() holds get_online_cpus() while registerring the hotplug callbacks. cpuhp_setup_state() invokes get_online_cpus() as well. This is correct, but prevents the conversion of the hotplug locking to a percpu rwsem. Use cpuhp_setup_state_cpuslocked() to

[patch V2 09/24] hwtracing/coresight-etm4x: Use cpuhp_setup_state_nocalls_cpuslocked()

From: Sebastian Andrzej Siewior etm_probe4() holds get_online_cpus() while invoking cpuhp_setup_state_nocalls(). cpuhp_setup_state_nocalls() invokes get_online_cpus() as well. This is correct, but prevents the conversion of the hotplug locking to a percpu rwsem. Use

[patch V2 06/24] cpufreq: Use cpuhp_setup_state_nocalls_cpuslocked()

From: Sebastian Andrzej Siewior cpufreq holds get_online_cpus() while invoking cpuhp_setup_state_nocalls() to make subsys_interface_register() and the registration of hotplug calls atomic versus cpu hotplug. cpuhp_setup_state_nocalls() invokes get_online_cpus() as well.

[patch V2 06/24] cpufreq: Use cpuhp_setup_state_nocalls_cpuslocked()

From: Sebastian Andrzej Siewior cpufreq holds get_online_cpus() while invoking cpuhp_setup_state_nocalls() to make subsys_interface_register() and the registration of hotplug calls atomic versus cpu hotplug. cpuhp_setup_state_nocalls() invokes get_online_cpus() as well. This is correct, but

Re: [PATCH 0/7] regulator: arizona: Prepare for sharing with Madera codecs

On Tue, Apr 18, 2017 at 11:43:46AM +0100, Richard Fitzgerald wrote: > These patches make various changes to the Arizona regulators so that they > can be re-used for the Cirrus Madera codecs: This all looks good to me but needs review from Lee for the MFD overlap. signature.asc Description: PGP

Re: [PATCH 0/7] regulator: arizona: Prepare for sharing with Madera codecs

On Tue, Apr 18, 2017 at 11:43:46AM +0100, Richard Fitzgerald wrote: > These patches make various changes to the Arizona regulators so that they > can be re-used for the Cirrus Madera codecs: This all looks good to me but needs review from Lee for the MFD overlap. signature.asc Description: PGP

[patch V2 05/24] x86/mtrr: Remove get_online_cpus() from mtrr_save_state()

From: Sebastian Andrzej Siewior mtrr_save_state() is invoked from native_cpu_up() which is in the context of a CPU hotplug operation and therefor calling get_online_cpus() is pointless. While this works in the current get_online_cpus() implementation it prevents from

[patch V2 05/24] x86/mtrr: Remove get_online_cpus() from mtrr_save_state()

From: Sebastian Andrzej Siewior mtrr_save_state() is invoked from native_cpu_up() which is in the context of a CPU hotplug operation and therefor calling get_online_cpus() is pointless. While this works in the current get_online_cpus() implementation it prevents from converting the hotplug

Re: [RFC 0/8] Copy Offload with Peer-to-Peer PCI Memory

On Tue, Apr 18, 2017 at 01:35:32PM -0600, Logan Gunthorpe wrote: > > Ultimately every dma_ops will need special code to support P2P with > > the special hardware that ops is controlling, so it makes some sense > > to start by pushing the check down there in the first place. This > > advice is

[patch V2 03/24] padata: Make padata_alloc() static

No users outside of padata.c Signed-off-by: Thomas Gleixner Cc: Steffen Klassert Cc: linux-cry...@vger.kernel.org --- include/linux/padata.h |3 --- kernel/padata.c| 32 2 files changed, 16

Re: [RFC 0/8] Copy Offload with Peer-to-Peer PCI Memory

On Tue, Apr 18, 2017 at 01:35:32PM -0600, Logan Gunthorpe wrote: > > Ultimately every dma_ops will need special code to support P2P with > > the special hardware that ops is controlling, so it makes some sense > > to start by pushing the check down there in the first place. This > > advice is

[patch V2 03/24] padata: Make padata_alloc() static

No users outside of padata.c Signed-off-by: Thomas Gleixner Cc: Steffen Klassert Cc: linux-cry...@vger.kernel.org --- include/linux/padata.h |3 --- kernel/padata.c| 32 2 files changed, 16 insertions(+), 19 deletions(-) ---

[patch V2 04/24] padata: Avoid nested calls to get_online_cpus() in pcrypt_init_padata()

From: Sebastian Andrzej Siewior pcrypt_init_padata() get_online_cpus() padata_alloc_possible() padata_alloc() get_online_cpus() The nested call to get_online_cpus() works with the current implementation, but prevents the conversion to a percpu rwsem.

[patch V2 04/24] padata: Avoid nested calls to get_online_cpus() in pcrypt_init_padata()

From: Sebastian Andrzej Siewior pcrypt_init_padata() get_online_cpus() padata_alloc_possible() padata_alloc() get_online_cpus() The nested call to get_online_cpus() works with the current implementation, but prevents the conversion to a percpu rwsem. The other caller of

[patch V2 02/24] stop_machine: Provide stop_machine_cpuslocked()

From: Sebastian Andrzej Siewior Some call sites of stop_machine() are within a get_online_cpus() protected region. stop_machine() calls get_online_cpus() as well, which is possible in the current implementation but prevents converting the hotplug locking to a percpu

[patch V2 02/24] stop_machine: Provide stop_machine_cpuslocked()

From: Sebastian Andrzej Siewior Some call sites of stop_machine() are within a get_online_cpus() protected region. stop_machine() calls get_online_cpus() as well, which is possible in the current implementation but prevents converting the hotplug locking to a percpu rwsem. Provide

Re: [RFC 0/8] Copy Offload with Peer-to-Peer PCI Memory

On Tue, Apr 18, 2017 at 12:35 PM, Logan Gunthorpe wrote: > > > On 18/04/17 01:01 PM, Jason Gunthorpe wrote: >> Ultimately every dma_ops will need special code to support P2P with >> the special hardware that ops is controlling, so it makes some sense >> to start by pushing

Re: [RFC 0/8] Copy Offload with Peer-to-Peer PCI Memory

On Tue, Apr 18, 2017 at 12:35 PM, Logan Gunthorpe wrote: > > > On 18/04/17 01:01 PM, Jason Gunthorpe wrote: >> Ultimately every dma_ops will need special code to support P2P with >> the special hardware that ops is controlling, so it makes some sense >> to start by pushing the check down there in

[patch V2 01/24] cpu/hotplug: Provide cpuhp_setup/remove_state[_nocalls]_cpuslocked()

From: Sebastian Andrzej Siewior Some call sites of cpuhp_setup/remove_state[_nocalls]() are within a get_online_cpus() protected region. cpuhp_setup/remove_state[_nocalls]() call get_online_cpus() as well, which is possible in the current implementation but prevents

[patch V2 01/24] cpu/hotplug: Provide cpuhp_setup/remove_state[_nocalls]_cpuslocked()

From: Sebastian Andrzej Siewior Some call sites of cpuhp_setup/remove_state[_nocalls]() are within a get_online_cpus() protected region. cpuhp_setup/remove_state[_nocalls]() call get_online_cpus() as well, which is possible in the current implementation but prevents converting the hotplug

[patch V2 00/24] cpu/hotplug: Convert get_online_cpus() to a percpu_rwsem

get_online_cpus() is used in hot pathes in mainline and even more so in RT. That can show up badly under certain conditions because every locker contends on a global mutex. RT has it's own homebrewn mitigation which is an (badly done) open coded implementation of percpu_rwsems with recursion

[patch V2 00/24] cpu/hotplug: Convert get_online_cpus() to a percpu_rwsem

get_online_cpus() is used in hot pathes in mainline and even more so in RT. That can show up badly under certain conditions because every locker contends on a global mutex. RT has it's own homebrewn mitigation which is an (badly done) open coded implementation of percpu_rwsems with recursion

Re: [PATCH v3] PCI: Make PCI_ROM_ADDRESS_MASK a 32-bit constant

On Fri, Apr 14, 2017 at 01:38:02PM -0700, Matthias Kaehlcke wrote: > A 64-bit value is not needed since a PCI ROM address consists in 32 bits. > This fixes a clang warning about "implicit conversion from 'unsigned > long' to 'u32'". > > Also remove now unnecessary casts to u32 from

Re: [PATCH v3] PCI: Make PCI_ROM_ADDRESS_MASK a 32-bit constant

On Fri, Apr 14, 2017 at 01:38:02PM -0700, Matthias Kaehlcke wrote: > A 64-bit value is not needed since a PCI ROM address consists in 32 bits. > This fixes a clang warning about "implicit conversion from 'unsigned > long' to 'u32'". > > Also remove now unnecessary casts to u32 from

Re: [PATCH v2 tip/core/rcu 04/39] srcu: Check for tardy grace-period activity in cleanup_srcu_struct()

On Tue, Apr 18, 2017 at 11:34:53AM -0700, Paul E. McKenney wrote: > On Mon, Apr 17, 2017 at 05:34:30PM -0700, Josh Triplett wrote: > > On Mon, Apr 17, 2017 at 05:33:32PM -0700, Josh Triplett wrote: > > > On Mon, Apr 17, 2017 at 04:44:51PM -0700, Paul E. McKenney wrote: > > > > Users of SRCU are

Re: [PATCH v2 tip/core/rcu 04/39] srcu: Check for tardy grace-period activity in cleanup_srcu_struct()

On Tue, Apr 18, 2017 at 11:34:53AM -0700, Paul E. McKenney wrote: > On Mon, Apr 17, 2017 at 05:34:30PM -0700, Josh Triplett wrote: > > On Mon, Apr 17, 2017 at 05:33:32PM -0700, Josh Triplett wrote: > > > On Mon, Apr 17, 2017 at 04:44:51PM -0700, Paul E. McKenney wrote: > > > > Users of SRCU are

Re: [patch 17/20] PCI: Use cpu_hotplug_disable() instead of get_online_cpus()

On Sat, Apr 15, 2017 at 07:01:24PM +0200, Thomas Gleixner wrote: > Converting the hotplug locking, i.e. get_online_cpus(), to a percpu rwsem > unearthed a circular lock dependency which was hidden from lockdep due to > the lockdep annotation of get_online_cpus() which prevents lockdep from >

Re: [patch 17/20] PCI: Use cpu_hotplug_disable() instead of get_online_cpus()

On Sat, Apr 15, 2017 at 07:01:24PM +0200, Thomas Gleixner wrote: > Converting the hotplug locking, i.e. get_online_cpus(), to a percpu rwsem > unearthed a circular lock dependency which was hidden from lockdep due to > the lockdep annotation of get_online_cpus() which prevents lockdep from >

Re: [PATCH 1/4] fs: fix data invalidation in the cleancache during direct IO

On Fri, Apr 14, 2017 at 05:07:50PM +0300, Andrey Ryabinin wrote: > Some direct write fs hooks call invalidate_inode_pages2[_range]() > conditionally iff mapping->nrpages is not zero. If page cache is empty, > buffered read following after direct IO write would get stale data from > the cleancache.

Re: [PATCH 1/4] fs: fix data invalidation in the cleancache during direct IO

On Fri, Apr 14, 2017 at 05:07:50PM +0300, Andrey Ryabinin wrote: > Some direct write fs hooks call invalidate_inode_pages2[_range]() > conditionally iff mapping->nrpages is not zero. If page cache is empty, > buffered read following after direct IO write would get stale data from > the cleancache.

Re: [RFC 0/8] Copy Offload with Peer-to-Peer PCI Memory

On 18/04/17 01:01 PM, Jason Gunthorpe wrote: > Ultimately every dma_ops will need special code to support P2P with > the special hardware that ops is controlling, so it makes some sense > to start by pushing the check down there in the first place. This > advice is partially motivated by how

Re: [RFC 0/8] Copy Offload with Peer-to-Peer PCI Memory

On 18/04/17 01:01 PM, Jason Gunthorpe wrote: > Ultimately every dma_ops will need special code to support P2P with > the special hardware that ops is controlling, so it makes some sense > to start by pushing the check down there in the first place. This > advice is partially motivated by how

Re: [PATCH] arm64: dts: allwinner: a64: Add UART2 pin nodes

Am 18.04.2017 um 07:34 schrieb Maxime Ripard: > On Fri, Apr 14, 2017 at 07:13:20PM +0200, Andreas Färber wrote: >> UART2 is exposed on the Pi connector of Pine64. Make a pinctrl node >> available at the SoC level, to simplify enabling UART2 via DT overlay. >> >> Signed-off-by: Andreas Färber

Re: [PATCH] arm64: dts: allwinner: a64: Add UART2 pin nodes

Am 18.04.2017 um 07:34 schrieb Maxime Ripard: > On Fri, Apr 14, 2017 at 07:13:20PM +0200, Andreas Färber wrote: >> UART2 is exposed on the Pi connector of Pine64. Make a pinctrl node >> available at the SoC level, to simplify enabling UART2 via DT overlay. >> >> Signed-off-by: Andreas Färber > >

Re: [PATCH v3] arm64: dts: rk3399: add support for firefly-rk3399 board

On Mon, 10 Apr 2017 11:50:13 +0800 Kever Yang wrote: > Firefly-rk3399 is a bord from T-Firefly, you can find detail about > it here: > http://en.t-firefly.com/en/firenow/Firefly_RK3399/ > > This patch add basic node for the board and make it able to bring > up. > >

Re: [PATCH v3] arm64: dts: rk3399: add support for firefly-rk3399 board

On Mon, 10 Apr 2017 11:50:13 +0800 Kever Yang wrote: > Firefly-rk3399 is a bord from T-Firefly, you can find detail about > it here: > http://en.t-firefly.com/en/firenow/Firefly_RK3399/ > > This patch add basic node for the board and make it able to bring > up. > > Peripheral works: > - usb

Re: [PATCH] X86: don't report PAT on CPUs that don't support it

On 04/18/17 12:07, Mikulas Patocka wrote: > In the file arch/x86/mm/pat.c, there's a variable __pat_enabled. The > variable is set to 1 by default and the function pat_init() sets > __pat_enabled to 0 if the CPU doesn't support PAT. > > However, on AMD K6-3 CPU, the processor initialization code

Re: [PATCH] X86: don't report PAT on CPUs that don't support it

On 04/18/17 12:07, Mikulas Patocka wrote: > In the file arch/x86/mm/pat.c, there's a variable __pat_enabled. The > variable is set to 1 by default and the function pat_init() sets > __pat_enabled to 0 if the CPU doesn't support PAT. > > However, on AMD K6-3 CPU, the processor initialization code

Re: RFC: WMI Enhancements

On Tuesday 18 April 2017 18:56:31 Darren Hart wrote: > On Tue, Apr 18, 2017 at 09:54:01AM +0200, Pali Rohár wrote: > > On Thursday 13 April 2017 17:39:56 mario.limoncie...@dell.com wrote: > > > > > No more than exists today with the dcdbas SMI interface > > > > > (which only if you manually run

Re: RFC: WMI Enhancements

On Tuesday 18 April 2017 18:56:31 Darren Hart wrote: > On Tue, Apr 18, 2017 at 09:54:01AM +0200, Pali Rohár wrote: > > On Thursday 13 April 2017 17:39:56 mario.limoncie...@dell.com wrote: > > > > > No more than exists today with the dcdbas SMI interface > > > > > (which only if you manually run

Re: RFC: WMI Enhancements

On Tuesday 18 April 2017 18:33:25 Darren Hart wrote: > On Tue, Apr 18, 2017 at 03:07:06PM +0200, Rafael Wysocki wrote: > > On Monday, April 17, 2017 04:10:51 PM Darren Hart wrote: > > > On Mon, Apr 17, 2017 at 03:03:29PM -0700, Andy Lutomirski wrote: > > > > On Fri, Apr 14, 2017 at 4:05 PM, Darren

Re: RFC: WMI Enhancements

On Tuesday 18 April 2017 18:33:25 Darren Hart wrote: > On Tue, Apr 18, 2017 at 03:07:06PM +0200, Rafael Wysocki wrote: > > On Monday, April 17, 2017 04:10:51 PM Darren Hart wrote: > > > On Mon, Apr 17, 2017 at 03:03:29PM -0700, Andy Lutomirski wrote: > > > > On Fri, Apr 14, 2017 at 4:05 PM, Darren

[PATCH] arm64: dts: allwinner: pine64: Prepare optional UART nodes with pinctrl

Pine64 exposes all A64 UARTs, not just UART0. Since the pins can be used as GPIO, don't enable the new UART nodes by default, but prepare the pinctrl settings to aid in activating them via overlays, i.e., overriding the status property of nodes. For UART4 (Euler) the safer route of not

[PATCH] arm64: dts: allwinner: pine64: Prepare optional UART nodes with pinctrl

Pine64 exposes all A64 UARTs, not just UART0. Since the pins can be used as GPIO, don't enable the new UART nodes by default, but prepare the pinctrl settings to aid in activating them via overlays, i.e., overriding the status property of nodes. For UART4 (Euler) the safer route of not

Re: [PATCH 1/3] drm/vc4: Turn the V3D clock on at runtime.

Eric Anholt writes: > For the Raspberry Pi's bindings, the power domain also implicitly > turns on the clock and deasserts reset, but for the new Cygnus port we > start representing the clock in the devicetree. > + v3d->clk = devm_clk_get(dev, "v3d_clk"); > + if

Re: [PATCH 1/3] drm/vc4: Turn the V3D clock on at runtime.

Eric Anholt writes: > For the Raspberry Pi's bindings, the power domain also implicitly > turns on the clock and deasserts reset, but for the new Cygnus port we > start representing the clock in the devicetree. > + v3d->clk = devm_clk_get(dev, "v3d_clk"); > + if (IS_ERR(v3d->clk)) { > +

Re: [PATCH 0/2] Cavium MMC driver smatch fixes

On 13 April 2017 at 14:10, Jan Glauber wrote: > Hi Ulf, > > here are two cosmetical changes for the reported smatch errors. > > Jan Glauber (2): > mmc: cavium: Remove redundant pointer check > mmc: cavium: Check pointer before de-reference > > drivers/mmc/host/cavium.c |

Re: [PATCH 0/2] Cavium MMC driver smatch fixes

On 13 April 2017 at 14:10, Jan Glauber wrote: > Hi Ulf, > > here are two cosmetical changes for the reported smatch errors. > > Jan Glauber (2): > mmc: cavium: Remove redundant pointer check > mmc: cavium: Check pointer before de-reference > > drivers/mmc/host/cavium.c | 4 ++-- > 1 file

Re: [PATCH] mmc: dw_mmc: Don't allow Runtime PM for SDIO cards

On 12 April 2017 at 00:55, Douglas Anderson wrote: > According to the SDIO standard interrupts are normally signalled in a > very complicated way. They require the card clock to be running and > require the controller to be paying close attention to the signals > coming

Re: [PATCH] mmc: dw_mmc: Don't allow Runtime PM for SDIO cards

On 12 April 2017 at 00:55, Douglas Anderson wrote: > According to the SDIO standard interrupts are normally signalled in a > very complicated way. They require the card clock to be running and > require the controller to be paying close attention to the signals > coming from the card. This

Re: [PATCH] device-mapper: Convert printks to pr_ macros

op us a note to > help improve the system] > > url: > https://github.com/0day-ci/linux/commits/Joe-Perches/device-mapper-Convert-printks-to-pr_-level-macros/20170418-030508 > config: i386-allmodconfig (attached as .config) > compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901

Re: [PATCH] device-mapper: Convert printks to pr_ macros

op us a note to > help improve the system] > > url: > https://github.com/0day-ci/linux/commits/Joe-Perches/device-mapper-Convert-printks-to-pr_-level-macros/20170418-030508 > config: i386-allmodconfig (attached as .config) > compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901

[PATCH 1/3] drm/vc4: Turn the V3D clock on at runtime.

For the Raspberry Pi's bindings, the power domain also implicitly turns on the clock and deasserts reset, but for the new Cygnus port we start representing the clock in the devicetree. Signed-off-by: Eric Anholt --- .../devicetree/bindings/display/brcm,bcm-vc4.txt | 3 ++

[PATCH 1/3] drm/vc4: Turn the V3D clock on at runtime.

For the Raspberry Pi's bindings, the power domain also implicitly turns on the clock and deasserts reset, but for the new Cygnus port we start representing the clock in the devicetree. Signed-off-by: Eric Anholt --- .../devicetree/bindings/display/brcm,bcm-vc4.txt | 3 ++

Re: [PATCH] PCI: Improve __pci_read_base robustness

On Mon, Apr 10, 2017 at 07:46:54PM +0200, Marc Gonzalez wrote: > Local variables 'l' and 'sz' are uninitialized. Normally, they would > be initialized by pci_read_config_dword() but when an error occurs, > some drivers immediately return an error code, which leaves the > argument uninitialized. >

Re: [PATCH] PCI: Improve __pci_read_base robustness

On Mon, Apr 10, 2017 at 07:46:54PM +0200, Marc Gonzalez wrote: > Local variables 'l' and 'sz' are uninitialized. Normally, they would > be initialized by pci_read_config_dword() but when an error occurs, > some drivers immediately return an error code, which leaves the > argument uninitialized. >

[PATCH 2/3] drm/vc4: Don't try to initialize FBDEV if we're only bound to V3D.

The FBDEV initialization would throw an error in dmesg, when we just want to silently not initialize fbdev on a V3D-only VC4 instance. Signed-off-by: Eric Anholt --- drivers/gpu/drm/vc4/vc4_kms.c | 10 ++ 1 file changed, 6 insertions(+), 4 deletions(-) diff --git

[PATCH 3/3] drm/vc4: Add specific compatible strings for Cygnus.

Cygnus has V3D 2.6 instead of 2.1, and doesn't use the VC4 display modules. The V3D can be uniquely identified by the IDENT[01] registers, and there's nothing to key off of for the display change other than the lack of DT nodes for the display components, but it's convention to have new

[PATCH 2/3] drm/vc4: Don't try to initialize FBDEV if we're only bound to V3D.

The FBDEV initialization would throw an error in dmesg, when we just want to silently not initialize fbdev on a V3D-only VC4 instance. Signed-off-by: Eric Anholt --- drivers/gpu/drm/vc4/vc4_kms.c | 10 ++ 1 file changed, 6 insertions(+), 4 deletions(-) diff --git

[PATCH 3/3] drm/vc4: Add specific compatible strings for Cygnus.

Cygnus has V3D 2.6 instead of 2.1, and doesn't use the VC4 display modules. The V3D can be uniquely identified by the IDENT[01] registers, and there's nothing to key off of for the display change other than the lack of DT nodes for the display components, but it's convention to have new

[PATCH] X86: don't report PAT on CPUs that don't support it

In the file arch/x86/mm/pat.c, there's a variable __pat_enabled. The variable is set to 1 by default and the function pat_init() sets __pat_enabled to 0 if the CPU doesn't support PAT. However, on AMD K6-3 CPU, the processor initialization code never calls pat_init() and so __pat_enabled stays 1

[PATCH] X86: don't report PAT on CPUs that don't support it

In the file arch/x86/mm/pat.c, there's a variable __pat_enabled. The variable is set to 1 by default and the function pat_init() sets __pat_enabled to 0 if the CPU doesn't support PAT. However, on AMD K6-3 CPU, the processor initialization code never calls pat_init() and so __pat_enabled stays 1

Re: [PATCH v2 2/3] mtd: dataflash: Improve coding style in jedec_probe()

On 04/18/2017 04:21 PM, Andrey Smirnov wrote: > As per request from Marek Vasut, change the following: Does that really have to be in the commit message ? ^_^' >- Replace indentation between type and name of local variable from > tabs to spaces > >- Replace magic number 0x1F with

Re: [PATCH 4/4] regulator: Add ROHM BD9571MWV-M PMIC regulator driver

On 04/18/2017 07:57 PM, Mark Brown wrote: > On Sun, Apr 16, 2017 at 08:08:01PM +0200, Marek Vasut wrote: > > This looks good, a couple of minor things though: > >> +static int bd9571mwv_regulator_is_enabled(struct regulator_dev *reg) >> +{ >> +/* Always enabled. */ >> +return 1; >> +} >

Re: [PATCH v2 2/3] mtd: dataflash: Improve coding style in jedec_probe()

On 04/18/2017 04:21 PM, Andrey Smirnov wrote: > As per request from Marek Vasut, change the following: Does that really have to be in the commit message ? ^_^' >- Replace indentation between type and name of local variable from > tabs to spaces > >- Replace magic number 0x1F with

Re: [PATCH 4/4] regulator: Add ROHM BD9571MWV-M PMIC regulator driver

On 04/18/2017 07:57 PM, Mark Brown wrote: > On Sun, Apr 16, 2017 at 08:08:01PM +0200, Marek Vasut wrote: > > This looks good, a couple of minor things though: > >> +static int bd9571mwv_regulator_is_enabled(struct regulator_dev *reg) >> +{ >> +/* Always enabled. */ >> +return 1; >> +} >

Re: [PATCH v2 1/3] mtd: dataflash: Replace C99 type with their kernel counterparts

On 04/18/2017 04:21 PM, Andrey Smirnov wrote: > Replace C99 type with their kernel counterparts as per request from > Marek Vasut. > > No functional change intended. > > Cc: cphe...@gmail.com > Cc: David Woodhouse > Cc: Brian Norris > Cc: Boris

Re: [PATCH v2 1/3] mtd: dataflash: Replace C99 type with their kernel counterparts

On 04/18/2017 04:21 PM, Andrey Smirnov wrote: > Replace C99 type with their kernel counterparts as per request from > Marek Vasut. > > No functional change intended. > > Cc: cphe...@gmail.com > Cc: David Woodhouse > Cc: Brian Norris > Cc: Boris Brezillon > Cc: Marek Vasut > Cc: Richard

Re: [PATCH v2 3/3] mtd: dataflash: Make use of "extened device information"

On 04/18/2017 04:21 PM, Andrey Smirnov wrote: > In anticipation of supporting chips that need it, extend the size of > struct flash_info's 'jedec_id' field to make room 2 byte of extended > device information as well as add code to fetch this data during > jedec_probe(). > > Cc: cphe...@gmail.com

Re: [PATCH v2 3/3] mtd: dataflash: Make use of "extened device information"

On 04/18/2017 04:21 PM, Andrey Smirnov wrote: > In anticipation of supporting chips that need it, extend the size of > struct flash_info's 'jedec_id' field to make room 2 byte of extended > device information as well as add code to fetch this data during > jedec_probe(). > > Cc: cphe...@gmail.com

Re: [RFC 0/8] Copy Offload with Peer-to-Peer PCI Memory

On Tue, Apr 18, 2017 at 12:30:59PM -0600, Logan Gunthorpe wrote: > > - The dma ops provider must be able to tell if source memory is bar > >mapped and recover the pci device backing the mapping. > > Do you mean to say that every dma-ops provider needs to be taught about > p2p backed pages?

Re: [RFC 0/8] Copy Offload with Peer-to-Peer PCI Memory

On Tue, Apr 18, 2017 at 12:30:59PM -0600, Logan Gunthorpe wrote: > > - The dma ops provider must be able to tell if source memory is bar > >mapped and recover the pci device backing the mapping. > > Do you mean to say that every dma-ops provider needs to be taught about > p2p backed pages?

Re: [PATCH v4 4/5] perf report: Show branch type statistics for stdio mode

On Wed, Apr 12, 2017 at 06:21:05AM +0800, Jin Yao wrote: SNIP > +const char *branch_type_name(int type) > +{ > + const char *branch_names[PERF_BR_MAX] = { > + "N/A", > + "JCC", > + "JMP", > + "IND_JMP", > + "CALL", > +

Re: [PATCH v4 4/5] perf report: Show branch type statistics for stdio mode

On Wed, Apr 12, 2017 at 06:21:05AM +0800, Jin Yao wrote: SNIP > +static int hist_iter__branch_callback(struct hist_entry_iter *iter, > + struct addr_location *al __maybe_unused, > + bool single __maybe_unused, > +

Re: [PATCH v4 4/5] perf report: Show branch type statistics for stdio mode

On Wed, Apr 12, 2017 at 06:21:05AM +0800, Jin Yao wrote: SNIP > +const char *branch_type_name(int type) > +{ > + const char *branch_names[PERF_BR_MAX] = { > + "N/A", > + "JCC", > + "JMP", > + "IND_JMP", > + "CALL", > +

Re: [PATCH v4 4/5] perf report: Show branch type statistics for stdio mode

On Wed, Apr 12, 2017 at 06:21:05AM +0800, Jin Yao wrote: SNIP > +static int hist_iter__branch_callback(struct hist_entry_iter *iter, > + struct addr_location *al __maybe_unused, > + bool single __maybe_unused, > +

Re: [PATCH v4 5/5] perf report: Show branch type in callchain entry

On Wed, Apr 12, 2017 at 06:21:06AM +0800, Jin Yao wrote: SNIP > +static int branch_type_str(struct branch_type_stat *stat, > +char *bf, int bfsize) > +{ > + int i, j = 0, printed = 0; > + u64 total = 0; > + > + for (i = 0; i < PERF_BR_MAX; i++) > +

Re: [PATCH v4 5/5] perf report: Show branch type in callchain entry

On Wed, Apr 12, 2017 at 06:21:06AM +0800, Jin Yao wrote: SNIP > +static int branch_type_str(struct branch_type_stat *stat, > +char *bf, int bfsize) > +{ > + int i, j = 0, printed = 0; > + u64 total = 0; > + > + for (i = 0; i < PERF_BR_MAX; i++) > +

Re: [PATCH v4 5/5] perf report: Show branch type in callchain entry

On Wed, Apr 12, 2017 at 06:21:06AM +0800, Jin Yao wrote: SNIP > static int counts_str_build(char *bf, int bfsize, >u64 branch_count, u64 predicted_count, >u64 abort_count, u64 cycles_count, > - u64 iter_count, u64

Re: [PATCH v4 5/5] perf report: Show branch type in callchain entry

On Wed, Apr 12, 2017 at 06:21:06AM +0800, Jin Yao wrote: SNIP > static int counts_str_build(char *bf, int bfsize, >u64 branch_count, u64 predicted_count, >u64 abort_count, u64 cycles_count, > - u64 iter_count, u64

Re: arch/x86//kernel/ftrace.c:35:3: error: #error The following combination is not supported: ((compiler missing -mfentry) || (CONFIG_X86_32 and !CONFIG_DYNAMIC_FTRACE)) && CONFIG_FUNCTION_GRAPH_TRACE

Josh Poimboeuf writes: > > The error is working as designed. gcc < 4.6.0 doesn't have -mfentry, so > it fails the above check on x86. Can you add a skip rule? It should > skip building the following case: > > x86 && ((gcc < 4.6.0) || (CONFIG_X86_32 and

Re: arch/x86//kernel/ftrace.c:35:3: error: #error The following combination is not supported: ((compiler missing -mfentry) || (CONFIG_X86_32 and !CONFIG_DYNAMIC_FTRACE)) && CONFIG_FUNCTION_GRAPH_TRACE

Josh Poimboeuf writes: > > The error is working as designed. gcc < 4.6.0 doesn't have -mfentry, so > it fails the above check on x86. Can you add a skip rule? It should > skip building the following case: > > x86 && ((gcc < 4.6.0) || (CONFIG_X86_32 and !CONFIG_DYNAMIC_FTRACE)) > &&

Re: [PATCH v17 2/3] usb: USB Type-C connector class

Hi Heikki, I have a question regarding the preferred_role node. +What: /sys/class/typec//preferred_role +Date: March 2017 +Contact: Heikki Krogerus +Description: + The user space can notify the driver about the preferred

Re: [PATCH v17 2/3] usb: USB Type-C connector class

Hi Heikki, I have a question regarding the preferred_role node. +What: /sys/class/typec//preferred_role +Date: March 2017 +Contact: Heikki Krogerus +Description: + The user space can notify the driver about the preferred role. + It should be

Re: [PATCH 2/4] fs/block_dev: always invalidate cleancache in invalidate_bdev()

On 14.04.2017 17:07, Andrey Ryabinin wrote: > invalidate_bdev() calls cleancache_invalidate_inode() iff ->nrpages != 0 > which doen't make any sense. > Make invalidate_bdev() always invalidate cleancache data. > > Fixes: c515e1fd361c ("mm/fs: add hooks to support cleancache") > Signed-off-by:

Re: [PATCH 2/4] fs/block_dev: always invalidate cleancache in invalidate_bdev()

On 14.04.2017 17:07, Andrey Ryabinin wrote: > invalidate_bdev() calls cleancache_invalidate_inode() iff ->nrpages != 0 > which doen't make any sense. > Make invalidate_bdev() always invalidate cleancache data. > > Fixes: c515e1fd361c ("mm/fs: add hooks to support cleancache") > Signed-off-by:

Re: [PATCH v2 00/27] PCI resource mmap cleanup

On Tue, Apr 18, 2017 at 01:28:16PM -0500, Bjorn Helgaas wrote: > On Wed, Apr 12, 2017 at 01:25:49PM +0100, David Woodhouse wrote: > > This pursues my previous patch set all the way to its logical conclusion. > > > > It kills off the legacy arch-provided pci_mmap_page_range() completely, > > along

Re: [PATCH v2 00/27] PCI resource mmap cleanup

On Tue, Apr 18, 2017 at 01:28:16PM -0500, Bjorn Helgaas wrote: > On Wed, Apr 12, 2017 at 01:25:49PM +0100, David Woodhouse wrote: > > This pursues my previous patch set all the way to its logical conclusion. > > > > It kills off the legacy arch-provided pci_mmap_page_range() completely, > > along

Re: [PATCH] arm64: xen: Implement EFI reset_system callback

On 18/04/17 20:46, Stefano Stabellini wrote: > On Tue, 18 Apr 2017, Juergen Gross wrote: >> On 18/04/17 20:37, Stefano Stabellini wrote: >>> On Thu, 6 Apr 2017, Juergen Gross wrote: On 06/04/17 18:43, Daniel Kiper wrote: > On Thu, Apr 06, 2017 at 06:22:44PM +0200, Juergen Gross wrote:

Re: [PATCH] arm64: xen: Implement EFI reset_system callback

On 18/04/17 20:46, Stefano Stabellini wrote: > On Tue, 18 Apr 2017, Juergen Gross wrote: >> On 18/04/17 20:37, Stefano Stabellini wrote: >>> On Thu, 6 Apr 2017, Juergen Gross wrote: On 06/04/17 18:43, Daniel Kiper wrote: > On Thu, Apr 06, 2017 at 06:22:44PM +0200, Juergen Gross wrote:

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