[RFC 6/9] arm64: add basic pointer authentication support

This patch adds basic support for pointer authentication, allowing userspace to make use of APIAKey. The kernel maintains an APIAKey value for each process (shared by all threads within), which is initialised to a random value at exec() time. Instructions using other keys (APIBKey, APDAKey,

[RFC 6/9] arm64: add basic pointer authentication support

This patch adds basic support for pointer authentication, allowing userspace to make use of APIAKey. The kernel maintains an APIAKey value for each process (shared by all threads within), which is initialised to a random value at exec() time. Instructions using other keys (APIBKey, APDAKey,

[RFC 8/9] arm64/kvm: context-switch PAC registers

If we have pointer authentication support, a guest may wish to use it. This patch adds the infrastructure to allow it to do so. This is sufficient for basic testing, but not for real-world usage. A guest will still see pointer authentication support advertised in the ID registers, and we will

[RFC 8/9] arm64/kvm: context-switch PAC registers

If we have pointer authentication support, a guest may wish to use it. This patch adds the infrastructure to allow it to do so. This is sufficient for basic testing, but not for real-world usage. A guest will still see pointer authentication support advertised in the ID registers, and we will

[RFC 9/9] arm64: docs: document pointer authentication

Now that we've added code to support pointer authentication, add some documentation so that people can figure out if/how to use it. Since there are new enable bits in SCR_EL3 (and HCR_EL2), I think we should document something in booting.txt w.r.t. functionality advertised via ID registers being

[RFC 9/9] arm64: docs: document pointer authentication

Now that we've added code to support pointer authentication, add some documentation so that people can figure out if/how to use it. Since there are new enable bits in SCR_EL3 (and HCR_EL2), I think we should document something in booting.txt w.r.t. functionality advertised via ID registers being

[RFC 4/9] arm64/cpufeature: detect pointer authentication

So that we can dynamically handle the presence of pointer authentication functionality, wire up probing code in cpufeature.c. Currently, this only detects the presence of an architected algorithm. Signed-off-by: Mark Rutland Cc: Catalin Marinas

[RFC 4/9] arm64/cpufeature: detect pointer authentication

So that we can dynamically handle the presence of pointer authentication functionality, wire up probing code in cpufeature.c. Currently, this only detects the presence of an architected algorithm. Signed-off-by: Mark Rutland Cc: Catalin Marinas Cc: Suzuki K Poulose Cc: Will Deacon ---

[RFC 5/9] arm64: Don't trap host pointer auth use to EL2

To allow EL0 (and/or EL1) to use pointer authentication functionality, we must ensure that pointer authentication instructions and accesses to pointer authentication keys are not trapped to EL2 (where we will not be able to handle them). This patch ensures that HCR_EL2 is configured appropriately

[RFC 5/9] arm64: Don't trap host pointer auth use to EL2

To allow EL0 (and/or EL1) to use pointer authentication functionality, we must ensure that pointer authentication instructions and accesses to pointer authentication keys are not trapped to EL2 (where we will not be able to handle them). This patch ensures that HCR_EL2 is configured appropriately

[RFC 3/9] arm64/cpufeature: add ARMv8.3 id_aa64isar1 bits

>From ARMv8.3 onwards, ID_AA64ISAR1 is no longer entirely RES0, and now has four fields describing the presence of pointer authentication functionality: * APA - address authentication present, using an architected algorithm * API - address authentication present, using an IMP DEF algorithm * GPA

Re: [RFC PATCH 1/4] fs: new infrastructure for writeback error handling and reporting

On Mon, 2017-04-03 at 07:47 -0700, Matthew Wilcox wrote: > On Fri, Mar 31, 2017 at 03:26:00PM -0400, Jeff Layton wrote: > > This set adds a wb_error field and a sequence counter to the > > address_space, and a corresponding sequence counter in the struct file. > > When errors are reported during

[RFC 3/9] arm64/cpufeature: add ARMv8.3 id_aa64isar1 bits

>From ARMv8.3 onwards, ID_AA64ISAR1 is no longer entirely RES0, and now has four fields describing the presence of pointer authentication functionality: * APA - address authentication present, using an architected algorithm * API - address authentication present, using an IMP DEF algorithm * GPA

Re: [RFC PATCH 1/4] fs: new infrastructure for writeback error handling and reporting

On Mon, 2017-04-03 at 07:47 -0700, Matthew Wilcox wrote: > On Fri, Mar 31, 2017 at 03:26:00PM -0400, Jeff Layton wrote: > > This set adds a wb_error field and a sequence counter to the > > address_space, and a corresponding sequence counter in the struct file. > > When errors are reported during

Re: [PATCH 2/3] dt-bindings: Add bindings for nvidia,tegra186-ccplex-cluster

On 04/03/2017 05:24 PM, Jon Hunter wrote: On 03/04/17 13:42, Mikko Perttunen wrote: The Tegra186 CCPLEX_CLUSTER area contains memory-mapped registers that initiate CPU frequency/voltage transitions. Signed-off-by: Mikko Perttunen ---

Re: [PATCH 2/3] dt-bindings: Add bindings for nvidia,tegra186-ccplex-cluster

On 04/03/2017 05:24 PM, Jon Hunter wrote: On 03/04/17 13:42, Mikko Perttunen wrote: The Tegra186 CCPLEX_CLUSTER area contains memory-mapped registers that initiate CPU frequency/voltage transitions. Signed-off-by: Mikko Perttunen --- .../arm/tegra/nvidia,tegra186-ccplex-cluster.txt | 22

[RFC 1/9] asm-generic: mm_hooks: allow hooks to be overridden individually

Currently, an architecture must either implement all of the mm hooks itself, or use all of those provided by the asm-generic implementation. When an architecture only needs to override a single hook, it must copy the stub implementations from the asm-generic version. To avoid this repetition,

[RFC 1/9] asm-generic: mm_hooks: allow hooks to be overridden individually

Currently, an architecture must either implement all of the mm hooks itself, or use all of those provided by the asm-generic implementation. When an architecture only needs to override a single hook, it must copy the stub implementations from the asm-generic version. To avoid this repetition,

Re: [PATCH 2/3] dt-bindings: Add bindings for nvidia,tegra186-ccplex-cluster

On 04/03/2017 05:06 PM, Thierry Reding wrote: On Mon, Apr 03, 2017 at 03:42:24PM +0300, Mikko Perttunen wrote: The Tegra186 CCPLEX_CLUSTER area contains memory-mapped registers that initiate CPU frequency/voltage transitions. Signed-off-by: Mikko Perttunen ---

Re: [PATCH 2/3] dt-bindings: Add bindings for nvidia,tegra186-ccplex-cluster

On 04/03/2017 05:06 PM, Thierry Reding wrote: On Mon, Apr 03, 2017 at 03:42:24PM +0300, Mikko Perttunen wrote: The Tegra186 CCPLEX_CLUSTER area contains memory-mapped registers that initiate CPU frequency/voltage transitions. Signed-off-by: Mikko Perttunen ---

Re: imx-drm: vblank wait timed out

2017-03-31 14:57 GMT+02:00 Philipp Zabel : > Hi Christian, > > On Fri, 2017-03-31 at 12:44 +0200, Christian Gmeiner wrote: >> Hi >> >> I get this from time to time on a 4.9.17 kernel: >> >> [3.353387] [ cut here ] >> [3.353408] WARNING: CPU:

Re: imx-drm: vblank wait timed out

2017-03-31 14:57 GMT+02:00 Philipp Zabel : > Hi Christian, > > On Fri, 2017-03-31 at 12:44 +0200, Christian Gmeiner wrote: >> Hi >> >> I get this from time to time on a 4.9.17 kernel: >> >> [3.353387] [ cut here ] >> [3.353408] WARNING: CPU: 0 PID: 1 at >>

Re: [PATCH v6 02/39] [media] dt-bindings: Add bindings for i.MX media driver

On Mon, Apr 03, 2017 at 09:07:43AM -0500, Rob Herring wrote: > On Tue, Mar 28, 2017 at 05:35:52PM -0700, Steve Longerbeam wrote: > > I assume if there's another binding doc in progress, it means > > someone is working on another Synopsys DW CSI-2 subdevice driver. > > Yes. see

Re: [PATCH v6 02/39] [media] dt-bindings: Add bindings for i.MX media driver

On Mon, Apr 03, 2017 at 09:07:43AM -0500, Rob Herring wrote: > On Tue, Mar 28, 2017 at 05:35:52PM -0700, Steve Longerbeam wrote: > > I assume if there's another binding doc in progress, it means > > someone is working on another Synopsys DW CSI-2 subdevice driver. > > Yes. see

Re: [PATCH v4 1/2] power: supply: ltc2941-battery-gauge: Add vendor to compatibles in binding

On Wed, Mar 29, 2017 at 12:00:56PM -0400, Javier Martinez Canillas wrote: > The DT binding document for LTC2941 and LTC2943 battery gauges did not use > a vendor prefix in the listed compatible strings. The driver says that the > manufacturer is Linear Technology which is "lltc" in

Re: [PATCH v4 1/2] power: supply: ltc2941-battery-gauge: Add vendor to compatibles in binding

On Wed, Mar 29, 2017 at 12:00:56PM -0400, Javier Martinez Canillas wrote: > The DT binding document for LTC2941 and LTC2943 battery gauges did not use > a vendor prefix in the listed compatible strings. The driver says that the > manufacturer is Linear Technology which is "lltc" in

Re: linux-next: manual merge of the xen-tip tree with the tip tree

On 03/04/17 16:38, Ingo Molnar wrote: > > * Juergen Gross wrote: > >>> So my suggestion would be: could you delay 75cd32d6093e for a week, and >>> then >>> merge it on top of a pulled in tip:x86/mm? I'll send that tree to Linus on >>> the >>> first day of the merge window

Re: linux-next: manual merge of the xen-tip tree with the tip tree

On 03/04/17 16:38, Ingo Molnar wrote: > > * Juergen Gross wrote: > >>> So my suggestion would be: could you delay 75cd32d6093e for a week, and >>> then >>> merge it on top of a pulled in tip:x86/mm? I'll send that tree to Linus on >>> the >>> first day of the merge window so there shouldn't

Re: [PATCH 1/7] mfd: cros-ec: Fix host command buffer size

On 03/04/17 16:30, Lee Jones wrote: > On Mon, 03 Apr 2017, Lee Jones wrote: > >> On Fri, 24 Mar 2017, Enric Balletbo i Serra wrote: >> >>> From: Vic Yang >>> >>> For SPI, we can get up to 32 additional bytes for response preamble. >>> The current overhead (2 bytes) may

Re: [PATCH 1/7] mfd: cros-ec: Fix host command buffer size

On 03/04/17 16:30, Lee Jones wrote: > On Mon, 03 Apr 2017, Lee Jones wrote: > >> On Fri, 24 Mar 2017, Enric Balletbo i Serra wrote: >> >>> From: Vic Yang >>> >>> For SPI, we can get up to 32 additional bytes for response preamble. >>> The current overhead (2 bytes) may cause problems when we

Re: 4.10.8 OOPS - BUG: unable to handle kernel NULL pointer dereference; IP: _raw_spin_lock+0x13/0x30

moving to https://bugzilla.kernel.org/show_bug.cgi?id=195229

Re: 4.10.8 OOPS - BUG: unable to handle kernel NULL pointer dereference; IP: _raw_spin_lock+0x13/0x30

moving to https://bugzilla.kernel.org/show_bug.cgi?id=195229

Re: [PATCH v1] reset: Make optional stuff optional for all users

On Mon, 2017-04-03 at 14:33 +, Shevchenko, Andriy wrote: > On Mon, 2017-04-03 at 17:31 +0300, Andy Shevchenko wrote: > > On Mon, 2017-04-03 at 16:27 +0200, Philipp Zabel wrote: > > > > > > > > int rstc_id; > > > > int ret; > > > > > > > > - if (!node) > > > > -

Re: [PATCH v1] reset: Make optional stuff optional for all users

On Mon, 2017-04-03 at 14:33 +, Shevchenko, Andriy wrote: > On Mon, 2017-04-03 at 17:31 +0300, Andy Shevchenko wrote: > > On Mon, 2017-04-03 at 16:27 +0200, Philipp Zabel wrote: > > > > > > > > int rstc_id; > > > > int ret; > > > > > > > > - if (!node) > > > > -

Re: [Intel-gfx] [BUG][REGRESSION] i915 gpu hangs under load

On Sun, 02 Apr 2017, Martin Kepplinger wrote: > Am 2. April 2017 13:50:26 MESZ schrieb Thorsten Leemhuis > : >>Lo! On 22.03.2017 11:36, Jani Nikula wrote: >>> On Wed, 22 Mar 2017, Martin Kepplinger wrote: I know something

Re: [Intel-gfx] [BUG][REGRESSION] i915 gpu hangs under load

On Sun, 02 Apr 2017, Martin Kepplinger wrote: > Am 2. April 2017 13:50:26 MESZ schrieb Thorsten Leemhuis > : >>Lo! On 22.03.2017 11:36, Jani Nikula wrote: >>> On Wed, 22 Mar 2017, Martin Kepplinger wrote: I know something similar is here:

Re: [PATCH 7/7] mfd: cros_ec: add RTC as mfd subdevice

On 03/04/17 16:25, Lee Jones wrote: > On Fri, 24 Mar 2017, Enric Balletbo i Serra wrote: > >> From: Stephen Barber >> >> If the EC supports RTC host commands, expose an RTC device. >> >> Signed-off-by: Stephen Barber >> Signed-off-by: Enric

Re: [PATCH 7/7] mfd: cros_ec: add RTC as mfd subdevice

On 03/04/17 16:25, Lee Jones wrote: > On Fri, 24 Mar 2017, Enric Balletbo i Serra wrote: > >> From: Stephen Barber >> >> If the EC supports RTC host commands, expose an RTC device. >> >> Signed-off-by: Stephen Barber >> Signed-off-by: Enric Balletbo i Serra >> --- >> drivers/mfd/cros_ec.c |

Re: [PATCH v6 02/39] [media] dt-bindings: Add bindings for i.MX media driver

On Mon, Apr 03, 2017 at 09:11:35AM -0500, Rob Herring wrote: > On Wed, Mar 29, 2017 at 09:39:05AM +0100, Russell King - ARM Linux wrote: > > On Tue, Mar 28, 2017 at 07:21:34PM -0500, Rob Herring wrote: > > > On Mon, Mar 27, 2017 at 7:40 PM, Steve Longerbeam > > > wrote: >

[PATCH] x86/tsc: fix multiple checkpatch warnings

Fixed style issues: * block comments * replaced ACCESS_ONCE with WRITE_ONCE * "EXPORT_SYMBOL should immediately follow its function" Plus fixed typo in comment. Signed-off-by: Abhishek Rose --- arch/x86/kernel/tsc.c | 22 -- 1 file changed, 12

[PATCH V7 4/7] mfd: da9061: MFD core support

From: Steve Twiss MFD support for DA9061 is provided as part of the DA9062 device driver. The registers header file adds two new chip variant IDs defined in DA9061 and DA9062 hardware. The core header file adds new software enumerations for listing the valid

Re: [PATCH v6 02/39] [media] dt-bindings: Add bindings for i.MX media driver

On Mon, Apr 03, 2017 at 09:11:35AM -0500, Rob Herring wrote: > On Wed, Mar 29, 2017 at 09:39:05AM +0100, Russell King - ARM Linux wrote: > > On Tue, Mar 28, 2017 at 07:21:34PM -0500, Rob Herring wrote: > > > On Mon, Mar 27, 2017 at 7:40 PM, Steve Longerbeam > > > wrote: > > > > Add bindings

[PATCH] x86/tsc: fix multiple checkpatch warnings

Fixed style issues: * block comments * replaced ACCESS_ONCE with WRITE_ONCE * "EXPORT_SYMBOL should immediately follow its function" Plus fixed typo in comment. Signed-off-by: Abhishek Rose --- arch/x86/kernel/tsc.c | 22 -- 1 file changed, 12 insertions(+), 10 deletions(-)

[PATCH V7 4/7] mfd: da9061: MFD core support

From: Steve Twiss MFD support for DA9061 is provided as part of the DA9062 device driver. The registers header file adds two new chip variant IDs defined in DA9061 and DA9062 hardware. The core header file adds new software enumerations for listing the valid DA9061 IRQs and a

[PATCH v3 4/4] ARM: dts: sun7i: Add can0_pins_a pinctrl settings

The A20 SoC has an on-board CAN controller. This patch adds the pinctrl settings for pins PH20 and PH21. This patch is adapted from the description in Documentation/devicetree/bindings/net/can/sun4i_can.txt Signed-off-by: Patrick Menschel ---

[PATCH v3 4/4] ARM: dts: sun7i: Add can0_pins_a pinctrl settings

The A20 SoC has an on-board CAN controller. This patch adds the pinctrl settings for pins PH20 and PH21. This patch is adapted from the description in Documentation/devicetree/bindings/net/can/sun4i_can.txt Signed-off-by: Patrick Menschel --- arch/arm/boot/dts/sun7i-a20.dtsi | 5 + 1 file

[PATCH v3 0/4] ARM: dts: sunxi: Add CAN node and can0_pins_a pinctrl settings

The Allwinner A10/A20 SoCs have an on-board CAN (Controller Area Network) controller. This patch adds the CAN core to the SoC's include files, sun4i-a10.dtsi and sun7i-a20.dtsi. On linux-can mailing list was a discussion about updating the device tree bindings https://lkml.org/lkml/2015/9/17/220

[PATCH v3 0/4] ARM: dts: sunxi: Add CAN node and can0_pins_a pinctrl settings

The Allwinner A10/A20 SoCs have an on-board CAN (Controller Area Network) controller. This patch adds the CAN core to the SoC's include files, sun4i-a10.dtsi and sun7i-a20.dtsi. On linux-can mailing list was a discussion about updating the device tree bindings https://lkml.org/lkml/2015/9/17/220

[PATCH v3 3/4] ARM: dts: sun7i: Add CAN node

The A20 SoC has an on-board CAN controller. This patch adds the device node. The CAN controller is inherited from the A10 SoC and uses the same driver. This patch is adapted from the description in Documentation/devicetree/bindings/net/can/sun4i_can.txt Signed-off-by: Patrick Menschel

[PATCH v3 3/4] ARM: dts: sun7i: Add CAN node

The A20 SoC has an on-board CAN controller. This patch adds the device node. The CAN controller is inherited from the A10 SoC and uses the same driver. This patch is adapted from the description in Documentation/devicetree/bindings/net/can/sun4i_can.txt Signed-off-by: Patrick Menschel ---

[PATCH v3 1/4] ARM: dts: sun4i: Add CAN node

The A10 SoC has an on-board CAN controller. This patch adds the device node. This patch is adapted from the description in Documentation/devicetree/bindings/net/can/sun4i_can.txt Signed-off-by: Patrick Menschel --- arch/arm/boot/dts/sun4i-a10.dtsi | 8 1 file

[PATCH v3 1/4] ARM: dts: sun4i: Add CAN node

The A10 SoC has an on-board CAN controller. This patch adds the device node. This patch is adapted from the description in Documentation/devicetree/bindings/net/can/sun4i_can.txt Signed-off-by: Patrick Menschel --- arch/arm/boot/dts/sun4i-a10.dtsi | 8 1 file changed, 8 insertions(+)

[PATCH v6 01/11] powerpc/powernv: Data structure and macros definitions

From: Hemant Kumar Create new header file "imc-pmu.h" to add the data structures and macros needed for IMC pmu support. Signed-off-by: Anju T Sudhakar Signed-off-by: Hemant Kumar Signed-off-by: Madhavan Srinivasan

[PATCH v6 02/11] powerpc/powernv: Autoload IMC device driver module

From: Hemant Kumar This patch does three things : - Enables "opal.c" to create a platform device for the IMC interface according to the appropriate compatibility string. - Find the reserved-memory region details from the system device tree and get the base

[PATCH v6 01/11] powerpc/powernv: Data structure and macros definitions

From: Hemant Kumar Create new header file "imc-pmu.h" to add the data structures and macros needed for IMC pmu support. Signed-off-by: Anju T Sudhakar Signed-off-by: Hemant Kumar Signed-off-by: Madhavan Srinivasan --- arch/powerpc/include/asm/imc-pmu.h | 68

[PATCH v6 02/11] powerpc/powernv: Autoload IMC device driver module

From: Hemant Kumar This patch does three things : - Enables "opal.c" to create a platform device for the IMC interface according to the appropriate compatibility string. - Find the reserved-memory region details from the system device tree and get the base address of HOMER (Reserved

[PATCH v3 2/4] ARM: dts: sun4i: Add can0_pins_a pinctrl settings

The A10 SoC has an on-board CAN controller. This patch adds the pinctrl settings for pins PH20 and PH21. This patch is adapted from the description in Documentation/devicetree/bindings/net/can/sun4i_can.txt Signed-off-by: Patrick Menschel ---

[PATCH v3 2/4] ARM: dts: sun4i: Add can0_pins_a pinctrl settings

The A10 SoC has an on-board CAN controller. This patch adds the pinctrl settings for pins PH20 and PH21. This patch is adapted from the description in Documentation/devicetree/bindings/net/can/sun4i_can.txt Signed-off-by: Patrick Menschel --- arch/arm/boot/dts/sun4i-a10.dtsi | 5 + 1 file

[PATCH v6 00/11] IMC Instrumentation Support

Power9 has In-Memory-Collection (IMC) infrastructure which contains various Performance Monitoring Units (PMUs) at Nest level (these are on-chip but off-core), Core level and Thread level. The Nest PMU counters are handled by a Nest IMC microcode which runs in the OCC (On-Chip Controller)

[PATCH v6 00/11] IMC Instrumentation Support

Power9 has In-Memory-Collection (IMC) infrastructure which contains various Performance Monitoring Units (PMUs) at Nest level (these are on-chip but off-core), Core level and Thread level. The Nest PMU counters are handled by a Nest IMC microcode which runs in the OCC (On-Chip Controller)

[PATCH v6 10/11] powerpc/perf: Thread IMC PMU functions

From: Hemant Kumar This patch adds the PMU functions required for event initialization, read, update, add, del etc. for thread IMC PMU. Thread IMC PMUs are used for per-task monitoring. These PMUs don't need any hotplugging support. For each CPU, a page of memory is

[PATCH v6 10/11] powerpc/perf: Thread IMC PMU functions

From: Hemant Kumar This patch adds the PMU functions required for event initialization, read, update, add, del etc. for thread IMC PMU. Thread IMC PMUs are used for per-task monitoring. These PMUs don't need any hotplugging support. For each CPU, a page of memory is allocated and is kept static

[PATCH v6 08/11] powerpc/perf: PMU functions for Core IMC and hotplugging

From: Hemant Kumar This patch adds the PMU function to initialize a core IMC event. It also adds cpumask initialization function for core IMC PMU. For initialization, a 8KB of memory is allocated per core where the data for core IMC counters will be accumulated. The

[PATCH v6 09/11] powerpc/powernv: Thread IMC events detection

From: Hemant Kumar Patch adds support for detection of thread IMC events. It adds a new domain IMC_DOMAIN_THREAD and it is determined with the help of the compatibility string "ibm,imc-counters-thread" based on the IMC device tree. Signed-off-by: Anju T Sudhakar

[PATCH v6 08/11] powerpc/perf: PMU functions for Core IMC and hotplugging

From: Hemant Kumar This patch adds the PMU function to initialize a core IMC event. It also adds cpumask initialization function for core IMC PMU. For initialization, a 8KB of memory is allocated per core where the data for core IMC counters will be accumulated. The base address for this page is

[PATCH v6 09/11] powerpc/powernv: Thread IMC events detection

From: Hemant Kumar Patch adds support for detection of thread IMC events. It adds a new domain IMC_DOMAIN_THREAD and it is determined with the help of the compatibility string "ibm,imc-counters-thread" based on the IMC device tree. Signed-off-by: Anju T Sudhakar Signed-off-by: Hemant Kumar

[PATCH v6 06/11] powerpc/perf: IMC pmu cpumask and cpu hotplug support

From: Hemant Kumar Adds cpumask attribute to be used by each IMC pmu. Only one cpu (any online CPU) from each chip for nest PMUs is designated to read counters. On CPU hotplug, dying CPU is checked to see whether it is one of the designated cpus, if yes, next online

[PATCH v6 07/11] powerpc/powernv: Core IMC events detection

From: Hemant Kumar This patch adds support for detection of core IMC events along with the Nest IMC events. It adds a new domain IMC_DOMAIN_CORE and its determined with the help of the compatibility string "ibm,imc-counters-core" based on the IMC device tree.

[PATCH v6 06/11] powerpc/perf: IMC pmu cpumask and cpu hotplug support

From: Hemant Kumar Adds cpumask attribute to be used by each IMC pmu. Only one cpu (any online CPU) from each chip for nest PMUs is designated to read counters. On CPU hotplug, dying CPU is checked to see whether it is one of the designated cpus, if yes, next online cpu from the same chip (for

[PATCH v6 07/11] powerpc/powernv: Core IMC events detection

From: Hemant Kumar This patch adds support for detection of core IMC events along with the Nest IMC events. It adds a new domain IMC_DOMAIN_CORE and its determined with the help of the compatibility string "ibm,imc-counters-core" based on the IMC device tree. Signed-off-by: Anju T Sudhakar

[PATCH v6 05/11] powerpc/perf: Generic imc pmu event functions

From: Hemant Kumar Since, the IMC counters' data are periodically fed to a memory location, the functions to read/update, start/stop, add/del can be generic and can be used by all IMC PMU units. This patch adds a set of generic imc pmu related event functions to be

[PATCH v6 04/11] powerpc/perf: Add event attribute and group to IMC pmus

From: Hemant Kumar Device tree IMC driver code parses the IMC units and their events. It passes the information to IMC pmu code which is placed in powerpc/perf as "imc-pmu.c". This patch creates only event attributes and attribute groups for the IMC pmus.

[PATCH v6 05/11] powerpc/perf: Generic imc pmu event functions

From: Hemant Kumar Since, the IMC counters' data are periodically fed to a memory location, the functions to read/update, start/stop, add/del can be generic and can be used by all IMC PMU units. This patch adds a set of generic imc pmu related event functions to be used by each imc pmu unit.

[PATCH v6 04/11] powerpc/perf: Add event attribute and group to IMC pmus

From: Hemant Kumar Device tree IMC driver code parses the IMC units and their events. It passes the information to IMC pmu code which is placed in powerpc/perf as "imc-pmu.c". This patch creates only event attributes and attribute groups for the IMC pmus. Signed-off-by: Anju T Sudhakar

Re: [PATCH v3 3/4] tty/serial: meson_uart: add the core clock handling to the driver

On Fri, 2017-03-31 at 18:54 +0200, Helmut Klein wrote: > This patch gets the core clock as provided by the DT and enables it. > The code was taken from Amlogic's serial driver, and was tested on my > board. > > Signed-off-by: Helmut Klein > --- >  

Re: [PATCH v3 3/4] tty/serial: meson_uart: add the core clock handling to the driver

On Fri, 2017-03-31 at 18:54 +0200, Helmut Klein wrote: > This patch gets the core clock as provided by the DT and enables it. > The code was taken from Amlogic's serial driver, and was tested on my > board. > > Signed-off-by: Helmut Klein > --- >  drivers/tty/serial/meson_uart.c | 10 ++

[PATCH v6 11/11] powerpc/perf: Thread imc cpuhotplug support

From: Anju T Sudhakar This patch adds support for thread IMC on cpuhotplug. When a cpu goes offline, the LDBAR for that cpu is disabled, and when it comes back online the previous ldbar value is written back to the LDBAR for that cpu. To register the hotplug functions

[PATCH v6 11/11] powerpc/perf: Thread imc cpuhotplug support

From: Anju T Sudhakar This patch adds support for thread IMC on cpuhotplug. When a cpu goes offline, the LDBAR for that cpu is disabled, and when it comes back online the previous ldbar value is written back to the LDBAR for that cpu. To register the hotplug functions for thread_imc, a new

[PATCH v6 03/11] powerpc/powernv: Detect supported IMC units and its events

From: Hemant Kumar Parse device tree to detect IMC units. Traverse through each IMC unit node to find supported events and corresponding unit/scale files (if any). Here is the DTS file for reference:

[PATCH v6 03/11] powerpc/powernv: Detect supported IMC units and its events

From: Hemant Kumar Parse device tree to detect IMC units. Traverse through each IMC unit node to find supported events and corresponding unit/scale files (if any). Here is the DTS file for reference: https://github.com/open-power/ima-catalog/blob/master/81E00612.4E0100.dts The device

Re: [PATCH 0/3] Add RTC support on STM32F746

Hi On 01/19/2017 02:45 PM, Amelie Delaunay wrote: This patchset enables STM32 RTC on STM32F746 MCU. Amelie Delaunay (3): ARM: dts: stm32: set HSE_RTC clock frequency to 1 MHz on stm32f746 ARM: dts: stm32: Add RTC support for STM32F746 MCU ARM: dts: stm32: enable RTC on stm32746g-eval

Re: [PATCH 0/3] Add RTC support on STM32F746

Hi On 01/19/2017 02:45 PM, Amelie Delaunay wrote: This patchset enables STM32 RTC on STM32F746 MCU. Amelie Delaunay (3): ARM: dts: stm32: set HSE_RTC clock frequency to 1 MHz on stm32f746 ARM: dts: stm32: Add RTC support for STM32F746 MCU ARM: dts: stm32: enable RTC on stm32746g-eval

Re: [PATCH] i2c: add sc18is600 driver

On Wed, Mar 29, 2017 at 04:03:39PM +0200, Sebastian Reichel wrote: > This adds an I²C master driver for SPI -> I²C bus bridge chips. > It currently supports NXP's SC18IS600 and SC18IS601, as well as > Silicon Labs' CP2120. The driver was only tested on SC18IS600. > > Signed-off-By: Sebastian

Re: [PATCH] i2c: add sc18is600 driver

On Wed, Mar 29, 2017 at 04:03:39PM +0200, Sebastian Reichel wrote: > This adds an I²C master driver for SPI -> I²C bus bridge chips. > It currently supports NXP's SC18IS600 and SC18IS601, as well as > Silicon Labs' CP2120. The driver was only tested on SC18IS600. > > Signed-off-By: Sebastian

Re: [PATCH] mm: Add additional consistency check

On Mon, Apr 03, 2017 at 09:03:50AM -0500, Christoph Lameter wrote: > On Mon, 3 Apr 2017, Michael Ellerman wrote: > > > At least in slab.c it seems that would allow you to "free" an object > > from one kmem_cache onto the array_cache of another kmem_cache, which > > seems fishy. But maybe there's

Re: [PATCH] mm: Add additional consistency check

On Mon, Apr 03, 2017 at 09:03:50AM -0500, Christoph Lameter wrote: > On Mon, 3 Apr 2017, Michael Ellerman wrote: > > > At least in slab.c it seems that would allow you to "free" an object > > from one kmem_cache onto the array_cache of another kmem_cache, which > > seems fishy. But maybe there's

Re: [PATCH v2 0/7] Add support for triggered buffer mode to STM32 ADC

Hi On 01/26/2017 03:28 PM, Fabrice Gasnier wrote: The following patches add support for triggered buffer mode. These are based on top of "Add PWM and IIO timer drivers for STM32" series. Reference: https://lkml.org/lkml/2017/1/20/116 STM32 ADC, can use either interrupts or DMA to collect data.

Re: [PATCH v2 0/7] Add support for triggered buffer mode to STM32 ADC

Hi On 01/26/2017 03:28 PM, Fabrice Gasnier wrote: The following patches add support for triggered buffer mode. These are based on top of "Add PWM and IIO timer drivers for STM32" series. Reference: https://lkml.org/lkml/2017/1/20/116 STM32 ADC, can use either interrupts or DMA to collect data.

Re: [PATCH v3 1/5] dt-bindings: update device tree binding for Allwinner PRCM CCUs

On Wed, Mar 29, 2017 at 06:42:42PM +0800, Icenowy Zheng wrote: > From: Icenowy Zheng > > Many Allwinner SoCs after A31 have a CCU in PRCM block. > > Give the ones on H3 and A64 compatible strings. > > Signed-off-by: Icenowy Zheng > --- > Changes in v3: > -

Re: [PATCH v3 1/5] dt-bindings: update device tree binding for Allwinner PRCM CCUs

On Wed, Mar 29, 2017 at 06:42:42PM +0800, Icenowy Zheng wrote: > From: Icenowy Zheng > > Many Allwinner SoCs after A31 have a CCU in PRCM block. > > Give the ones on H3 and A64 compatible strings. > > Signed-off-by: Icenowy Zheng > --- > Changes in v3: > - Removed frequency info of iosc in

Re: [RFC PATCH 0/4] fs: introduce new writeback error tracking infrastructure and convert ext4 to use it

On Mon, Apr 03, 2017 at 02:25:11PM +1000, NeilBrown wrote: > I don't like that you need to add a 'flush' handler to every filesystem, > most of which just call > +return filemap_report_wb_error(file); > > Could we just have > if (filp->f_op->flush) > retval =

Re: [RFC PATCH 0/4] fs: introduce new writeback error tracking infrastructure and convert ext4 to use it

On Mon, Apr 03, 2017 at 02:25:11PM +1000, NeilBrown wrote: > I don't like that you need to add a 'flush' handler to every filesystem, > most of which just call > +return filemap_report_wb_error(file); > > Could we just have > if (filp->f_op->flush) > retval =

Re: [PATCH v3 2/2] PCI: Add tango PCIe host bridge support

On Wed, Mar 29, 2017 at 01:34:45PM +0200, Marc Gonzalez wrote: > This driver is used to work around HW bugs in the controller. > > Note: the controller does NOT support the following features. > > Legacy PCI interrupts > IO space > > Signed-off-by: Marc Gonzalez

Re: [PATCH v3 2/2] PCI: Add tango PCIe host bridge support

On Wed, Mar 29, 2017 at 01:34:45PM +0200, Marc Gonzalez wrote: > This driver is used to work around HW bugs in the controller. > > Note: the controller does NOT support the following features. > > Legacy PCI interrupts > IO space > > Signed-off-by: Marc Gonzalez > --- >

Re: [RFC PATCH 1/4] fs: new infrastructure for writeback error handling and reporting

On Fri, Mar 31, 2017 at 03:26:00PM -0400, Jeff Layton wrote: > This set adds a wb_error field and a sequence counter to the > address_space, and a corresponding sequence counter in the struct file. > When errors are reported during writeback, we set the error field in the > mapping and increment

Re: [RFC PATCH 1/4] fs: new infrastructure for writeback error handling and reporting

On Fri, Mar 31, 2017 at 03:26:00PM -0400, Jeff Layton wrote: > This set adds a wb_error field and a sequence counter to the > address_space, and a corresponding sequence counter in the struct file. > When errors are reported during writeback, we set the error field in the > mapping and increment

Re: [PATCH 1/3] cpufreq: Add Tegra186 cpufreq driver

On Mon, Apr 03, 2017 at 03:42:23PM +0300, Mikko Perttunen wrote: > Add a new cpufreq driver for Tegra186 (and likely later). > The CPUs are organized into two clusters, Denver and A57, > with two and four cores respectively. CPU frequency can be > adjusted by writing the desired rate divisor and a

Re: [PATCH v3] Allow user probes on versioned symbols

Em Fri, Mar 31, 2017 at 02:38:11PM -0500, Paul Clarke escreveu: > On 03/31/2017 12:31 PM, Arnaldo Carvalho de Melo wrote: > > Em Fri, Mar 31, 2017 at 11:06:16AM -0500, Paul Clarke escreveu: > > > Symbol versioning, as in glibc, results in symbols being defined as: > > > @[@] > > > (Note that "@@"

Re: [PATCH 1/3] cpufreq: Add Tegra186 cpufreq driver

On Mon, Apr 03, 2017 at 03:42:23PM +0300, Mikko Perttunen wrote: > Add a new cpufreq driver for Tegra186 (and likely later). > The CPUs are organized into two clusters, Denver and A57, > with two and four cores respectively. CPU frequency can be > adjusted by writing the desired rate divisor and a

Re: [PATCH v3] Allow user probes on versioned symbols

Em Fri, Mar 31, 2017 at 02:38:11PM -0500, Paul Clarke escreveu: > On 03/31/2017 12:31 PM, Arnaldo Carvalho de Melo wrote: > > Em Fri, Mar 31, 2017 at 11:06:16AM -0500, Paul Clarke escreveu: > > > Symbol versioning, as in glibc, results in symbols being defined as: > > > @[@] > > > (Note that "@@"

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