Linux-ARM-Kernel Archive on lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH] arm64: allwinner: a64-amarula-relic: Enable AP6330 WiFi support
From: Maxime Ripard @ 2018-05-31  9:39 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <20180529172238.9718-1-jagan@amarulasolutions.com>

Hi,

On Tue, May 29, 2018 at 10:52:38PM +0530, Jagan Teki wrote:
> +&rtc {
> +	clock-output-names = "rtc-osc32k", "rtc-osc32k-out";
> +	clocks = <&osc32k>;
> +	#clock-cells = <1>;
> +};

It should be in the DTSI

Maxime

-- 
Maxime Ripard, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20180531/51f74d7b/attachment.sig>

^ permalink raw reply

* [PATCH v5 10/15] ARM: spectre-v2: warn about incorrect context switching functions
From: Russell King - ARM Linux @ 2018-05-31  9:49 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <86r2lu9yzf.wl-marc.zyngier@arm.com>

On Tue, May 29, 2018 at 06:02:28PM +0100, Marc Zyngier wrote:
> On Tue, 29 May 2018 15:55:01 +0100,
> Russell King wrote:
> > 
> > Warn at error level if the context switching function is not what we
> > are expecting.  This can happen with big.Little systems, which we
> > currently do not support.
> > 
> > Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
> > Boot-tested-by: Tony Lindgren <tony@atomide.com>
> > Reviewed-by: Tony Lindgren <tony@atomide.com>
> 
> I assume this is a temporary situation until the ARM port grows the
> necessary infrastructure to support this mitigation on heterogeneous
> systems.

As I've said, I think that is going to be a very difficult problem to
resolve.  I detailed why in previous emails, but it seems each time I
do that, no one bothers to respond (presumably because no one has any
ideas how to sort that problem either.)

I believe that it's better to get some of the mitigations in the kernel
and warn about non-supported setups than it is to hold it back.

I notice that you haven't replied to some of the patches (7 and 8),
which makes me think that you have an issue with them - and as tonight
is likely the last linux-next before the merge window, we're basically
out of time to do another respin if there's something you don't like
there and if we want to get them in during the next merge window.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up

^ permalink raw reply

* [PATCH v5 10/15] ARM: spectre-v2: warn about incorrect context switching functions
From: Marc Zyngier @ 2018-05-31 10:07 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <20180531094922.GQ17671@n2100.armlinux.org.uk>

On 31/05/18 10:49, Russell King - ARM Linux wrote:
> On Tue, May 29, 2018 at 06:02:28PM +0100, Marc Zyngier wrote:
>> On Tue, 29 May 2018 15:55:01 +0100,
>> Russell King wrote:
>>>
>>> Warn at error level if the context switching function is not what we
>>> are expecting.  This can happen with big.Little systems, which we
>>> currently do not support.
>>>
>>> Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
>>> Boot-tested-by: Tony Lindgren <tony@atomide.com>
>>> Reviewed-by: Tony Lindgren <tony@atomide.com>
>>
>> I assume this is a temporary situation until the ARM port grows the
>> necessary infrastructure to support this mitigation on heterogeneous
>> systems.
> 
> As I've said, I think that is going to be a very difficult problem to
> resolve.  I detailed why in previous emails, but it seems each time I
> do that, no one bothers to respond (presumably because no one has any
> ideas how to sort that problem either.)
> 
> I believe that it's better to get some of the mitigations in the kernel
> and warn about non-supported setups than it is to hold it back.

I agree with you that it is better to get this merged quickly, and then
address exotic configurations (which are unfortunately quite common
these days) separately. I haven't had the time to try and understand how
to fix it though.

> I notice that you haven't replied to some of the patches (7 and 8),
> which makes me think that you have an issue with them - and as tonight
> is likely the last linux-next before the merge window, we're basically
> out of time to do another respin if there's something you don't like
> there and if we want to get them in during the next merge window.
Patches 7 and 8 didn't compile for me, and I had to fix-up things
manually in order to test it. Not that it should hold you back from
merging it.

Thanks,

	M.
-- 
Jazz is not dead. It just smells funny...

^ permalink raw reply

* [PATCH v5 10/15] ARM: spectre-v2: warn about incorrect context switching functions
From: Russell King - ARM Linux @ 2018-05-31 10:11 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <b91753a0-7c47-1e46-6884-4643a90afdc7@arm.com>

On Thu, May 31, 2018 at 11:07:18AM +0100, Marc Zyngier wrote:
> > I notice that you haven't replied to some of the patches (7 and 8),
> > which makes me think that you have an issue with them - and as tonight
> > is likely the last linux-next before the merge window, we're basically
> > out of time to do another respin if there's something you don't like
> > there and if we want to get them in during the next merge window.
> Patches 7 and 8 didn't compile for me, and I had to fix-up things
> manually in order to test it. Not that it should hold you back from
> merging it.

As noted in a reply to the cover, I made a mistake merging some changes
in that resulted in a simple-to-fix build error (a 'void' instead of a
'bool' return type.)  I wasn't going to send the series out for a third
time on the same day just because of that.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up

^ permalink raw reply

* [PATCH v2 3/6] clk: ti: dra7: Add clkctrl clock data for the mcan clocks
From: Faiz Abbas @ 2018-05-31 10:14 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <20180531040350.GA25132@rob-hp-laptop>

Hi,

On Thursday 31 May 2018 09:33 AM, Rob Herring wrote:
> On Wed, May 30, 2018 at 07:41:30PM +0530, Faiz Abbas wrote:
>> Add clkctrl data for the m_can clocks and register it within the
...
>>  
>> diff --git a/include/dt-bindings/clock/dra7.h b/include/dt-bindings/clock/dra7.h
>> index 5e1061b15aed..d7549c57cac3 100644
>> --- a/include/dt-bindings/clock/dra7.h
>> +++ b/include/dt-bindings/clock/dra7.h
>> @@ -168,5 +168,6 @@
>>  #define DRA7_COUNTER_32K_CLKCTRL	DRA7_CLKCTRL_INDEX(0x50)
>>  #define DRA7_UART10_CLKCTRL	DRA7_CLKCTRL_INDEX(0x80)
>>  #define DRA7_DCAN1_CLKCTRL	DRA7_CLKCTRL_INDEX(0x88)
>> +#define DRA7_ADC_CLKCTRL	DRA7_CLKCTRL_INDEX(0xa0)
> 
> ADC and mcan are the same thing?
> 

The register to control MCAN clocks is called ADC_CLKCTRL, Yes.

Thanks,
Faiz

^ permalink raw reply

* [PATCH v2 4/6] bus: ti-sysc: Add support for using ti-sysc for MCAN on dra76x
From: Faiz Abbas @ 2018-05-31 10:16 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <20180530145726.GD5705@atomide.com>

Hi,

On Wednesday 30 May 2018 08:27 PM, Tony Lindgren wrote:
> * Faiz Abbas <faiz_abbas@ti.com> [180530 14:12]:
>> The dra76x MCAN generic interconnect module has a its own
>> format for the bits in the control registers.
...
>>  static int sysc_init_pdata(struct sysc *ddata)
>>  {
>>  	struct ti_sysc_platform_data *pdata = dev_get_platdata(ddata->dev);
>> @@ -1441,6 +1457,7 @@ static const struct of_device_id sysc_match[] = {
>>  	{ .compatible = "ti,sysc-mcasp", .data = &sysc_omap4_mcasp, },
>>  	{ .compatible = "ti,sysc-usb-host-fs",
>>  	  .data = &sysc_omap4_usb_host_fs, },
>> +	{ .compatible = "ti,sysc-dra7-mcan", .data = &sysc_dra7_mcan, },
>>  	{  },
>>  };
> 
> Looks good to me. And presumably you checked that no other dra7 modules
> use sysconfig register bit layout like this?
> 

As far as I could see, Yes.

Thanks,
Faiz

^ permalink raw reply

* [PATCH v2 5/6] ARM: dts: Add generic interconnect target module node for MCAN
From: Faiz Abbas @ 2018-05-31 10:21 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <20180530150402.GE5705@atomide.com>

Hi,

On Wednesday 30 May 2018 08:34 PM, Tony Lindgren wrote:
> * Faiz Abbas <faiz_abbas@ti.com> [180530 14:12]:
>> The ti-sysc driver provides support for manipulating the idlemodes
>> and interconnect level resets.
> ...
>> --- a/arch/arm/boot/dts/dra76x.dtsi
>> +++ b/arch/arm/boot/dts/dra76x.dtsi
>> @@ -11,6 +11,25 @@
>>  / {
>>  	compatible = "ti,dra762", "ti,dra7";
>>  
>> +	ocp {
>> +
>> +		target-module at 0x42c00000 {
>> +			compatible = "ti,sysc-dra7-mcan";
>> +			ranges = <0x0 0x42c00000 0x2000>;
>> +			#address-cells = <1>;
>> +			#size-cells = <1>;
>> +			reg = <0x42c01900 0x4>,
>> +			      <0x42c01904 0x4>,
>> +			      <0x42c01908 0x4>;
>> +			reg-names = "rev", "sysc", "syss";
>> +			ti,sysc-mask = <(SYSC_OMAP4_SOFTRESET |
>> +					 SYSC_DRA7_MCAN_ENAWAKEUP)>;
>> +			ti,syss-mask = <1>;
>> +			clocks = <&wkupaon_clkctrl DRA7_ADC_CLKCTRL 0>;
>> +			clock-names = "fck";
>> +		};
>> +	};
>> +
>>  };
> 
> Looks good to me except I think the reset won't do anything currently
> with ti-sysc.c unless you specfify also "ti,hwmods" for the module?
> 
> Can you please check? It might be worth adding the reset function to
> ti-sysc.c for non "ti,hwmods" case and that just might remove the
> need for any hwmod code for this module.
> 

If I understand correctly, this involves adding a (*reset_module) in
ti_sysc_platform_data and defining a ti_sysc_reset_module() in ti-sysc.c
similar to ti_sysc_idle_module(). Right?

Thanks,
Faiz

^ permalink raw reply

* [PATCH v4 1/7] dt-bindings: clk: at91: add an I2S mux clock
From: Codrin Ciubotariu @ 2018-05-31 10:25 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <20180531005827.GA17203@rob-hp-laptop>

On 31.05.2018 03:58, Rob Herring wrote:
> On Fri, May 25, 2018 at 03:34:22PM +0300, Codrin Ciubotariu wrote:
>> The I2S mux clock can be used to select the I2S input clock. The
>> available parents are the peripheral and the generated clocks.
>>
>> Signed-off-by: Codrin Ciubotariu <codrin.ciubotariu@microchip.com>
>> ---
>>   .../devicetree/bindings/clock/at91-clock.txt       | 34 ++++++++++++++++++++++
>>   1 file changed, 34 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/clock/at91-clock.txt b/Documentation/devicetree/bindings/clock/at91-clock.txt
>> index 51c259a..1c46b3c 100644
>> --- a/Documentation/devicetree/bindings/clock/at91-clock.txt
>> +++ b/Documentation/devicetree/bindings/clock/at91-clock.txt
>> @@ -90,6 +90,8 @@ Required properties:
>>   	"atmel,sama5d2-clk-audio-pll-pmc"
>>   		at91 audio pll output on AUDIOPLLCLK that feeds the PMC
>>   		and can be used by peripheral clock or generic clock
>> +	"atmel,sama5d2-clk-i2s-mux":
>> +		at91 I2S clock source selection
> 
> Is this boolean or takes some values. If latter, what are valid values?

This is the compatible string of the clock driver.

> 
>>   
>>   Required properties for SCKC node:
>>   - reg : defines the IO memory reserved for the SCKC.
>> @@ -507,3 +509,35 @@ For example:
>>   			atmel,clk-output-range = <0 83000000>;
>>   		};
>>   	};
>> +
>> +Required properties for I2S mux clocks:
>> +- #size-cells : shall be 0 (reg is used to encode I2S bus id).
>> +- #address-cells : shall be 1 (reg is used to encode I2S bus id).
>> +- name: device tree node describing a specific mux clock.
>> +	* #clock-cells : from common clock binding; shall be set to 0.
>> +	* clocks : shall be the mux clock parent phandles; shall be 2 phandles:
>> +	  peripheral and generated clock; the first phandle shall belong to the
>> +	  peripheral clock and the second one shall belong to the generated
>> +	  clock; "clock-indices" property can be user to specify
>> +	  the correct order.
>> +	* reg: I2S bus id of the corresponding mux clock.
>> +	  e.g. reg = <0>; for i2s0, reg = <1>; for i2s1
>> +
>> +For example:
>> +	i2s_clkmux {
> 
> What is this a child of?

It is a child of PMC node, since both parent clocks are generated by PMC.

> 
>> +		compatible = "atmel,sama5d2-clk-i2s-mux";
>> +		#address-cells = <1>;
>> +		#size-cells = <0>;
> 
> How do you address this block? My guess is you don't because it is just
> part of some other block and you are just creating this node to
> instantiate a driver. Just make the node for the actual h/w block a
> clock provider and define the clock ids (0 and 1).

This block is not addressed, but its children are. The register we 
access in this driver is not part of other block. It's a SFR register, 
accessed through syscon and it has nothing to do with the I2S IP (see 
SAMA5D2 DS, page 1256, fig. 44-1: I2SC Block Diagram) that is the 
consumer of this clock. Adding a clock-id property in the I2S node would 
be just like v3 of this series, with the difference that we use clock-id 
instead of alias id to set the clock parent, which is not how you 
suggested back then.

Thank you for your review.

Best regards,
Codrin

[...]

^ permalink raw reply

* [PATCH v2 0/2] mark tramp_pg_dir read-only
From: Jun Yao @ 2018-05-31 10:30 UTC (permalink / raw)
  To: linux-arm-kernel

Version 2 changes:
	split tramp_pg_dir off from the data segment and create
	a dedicated pgdir segment for it.

Jun Yao (2):
  arm64/mm: split tramp_pg_dir off from the data segment
  arm64/mm: make tramp_pg_dir read-only

 arch/arm64/include/asm/sections.h |  1 +
 arch/arm64/kernel/vmlinux.lds.S   |  3 +++
 arch/arm64/mm/mmu.c               | 19 +++++++++++++++++++
 3 files changed, 23 insertions(+)

-- 
2.17.0

^ permalink raw reply

* [PATCH v2 1/2] arm64/mm: split tramp_pg_dir off from the data segment
From: Jun Yao @ 2018-05-31 10:31 UTC (permalink / raw)
  To: linux-arm-kernel

In order to make tramp_pg_dir read-only, split it off from the data
segment and create a dedicated pgdir segment for it.

Signed-off-by: Jun Yao <yaojun8558363@gmail.com>
---
 arch/arm64/include/asm/sections.h |  1 +
 arch/arm64/kernel/vmlinux.lds.S   |  3 +++
 arch/arm64/mm/mmu.c               | 13 +++++++++++++
 3 files changed, 17 insertions(+)

diff --git a/arch/arm64/include/asm/sections.h b/arch/arm64/include/asm/sections.h
index caab039d6305..46a6646e886b 100644
--- a/arch/arm64/include/asm/sections.h
+++ b/arch/arm64/include/asm/sections.h
@@ -29,5 +29,6 @@ extern char __inittext_begin[], __inittext_end[];
 extern char __irqentry_text_start[], __irqentry_text_end[];
 extern char __mmuoff_data_start[], __mmuoff_data_end[];
 extern char __entry_tramp_text_start[], __entry_tramp_text_end[];
+extern char __tramp_pgdir_segment_start[], __tramp_pgdir_segment_end[];
 
 #endif /* __ASM_SECTIONS_H */
diff --git a/arch/arm64/kernel/vmlinux.lds.S b/arch/arm64/kernel/vmlinux.lds.S
index 605d1b60469c..c3368782171d 100644
--- a/arch/arm64/kernel/vmlinux.lds.S
+++ b/arch/arm64/kernel/vmlinux.lds.S
@@ -220,8 +220,11 @@ SECTIONS
 	. += IDMAP_DIR_SIZE;
 
 #ifdef CONFIG_UNMAP_KERNEL_AT_EL0
+	. = ALIGN(SEGMENT_ALIGN);
+	__tramp_pgdir_segment_start = .;
 	tramp_pg_dir = .;
 	. += PAGE_SIZE;
+	__tramp_pgdir_segment_end = .;
 #endif
 
 #ifdef CONFIG_ARM64_SW_TTBR0_PAN
diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
index 2dbb2c9f1ec1..a675fb88914e 100644
--- a/arch/arm64/mm/mmu.c
+++ b/arch/arm64/mm/mmu.c
@@ -573,6 +573,9 @@ static void __init map_kernel(pgd_t *pgdp)
 {
 	static struct vm_struct vmlinux_text, vmlinux_rodata, vmlinux_inittext,
 				vmlinux_initdata, vmlinux_data;
+#ifdef CONFIG_UNMAP_KERNEL_AT_EL0
+	static struct vm_struct vmlinux_tramp_pgdir, vmlinux_data_end;
+#endif
 
 	/*
 	 * External debuggers may need to write directly to the text
@@ -593,7 +596,17 @@ static void __init map_kernel(pgd_t *pgdp)
 			   &vmlinux_inittext, 0, VM_NO_GUARD);
 	map_kernel_segment(pgdp, __initdata_begin, __initdata_end, PAGE_KERNEL,
 			   &vmlinux_initdata, 0, VM_NO_GUARD);
+#ifdef CONFIG_UNMAP_KERNEL_AT_EL0
+	map_kernel_segment(pgdp, _data, __tramp_pgdir_segment_start,
+			PAGE_KERNEL, &vmlinux_data, 0, VM_NO_GUARD);
+	map_kernel_segment(pgdp, __tramp_pgdir_segment_start,
+			__tramp_pgdir_segment_end, PAGE_KERNEL,
+			&vmlinux_tramp_pgdir, NO_CONT_MAPPINGS, VM_NO_GUARD);
+	map_kernel_segment(pgdp, __tramp_pgdir_segment_end, _end, PAGE_KERNEL,
+			&vmlinux_data_end, 0, 0);
+#else
 	map_kernel_segment(pgdp, _data, _end, PAGE_KERNEL, &vmlinux_data, 0, 0);
+#endif
 
 	if (!READ_ONCE(pgd_val(*pgd_offset_raw(pgdp, FIXADDR_START)))) {
 		/*
-- 
2.17.0

^ permalink raw reply related

* [PATCH v2 2/2] arm64/mm: make tramp_pg_dir read-only
From: Jun Yao @ 2018-05-31 10:31 UTC (permalink / raw)
  To: linux-arm-kernel

Make tramp_pg_dir read-only.

Signed-off-by: Jun Yao <yaojun8558363@gmail.com>
---
 arch/arm64/mm/mmu.c | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
index a675fb88914e..2c6e6433090c 100644
--- a/arch/arm64/mm/mmu.c
+++ b/arch/arm64/mm/mmu.c
@@ -542,6 +542,7 @@ static int __init map_entry_trampoline(void)
 {
 	pgprot_t prot = rodata_enabled ? PAGE_KERNEL_ROX : PAGE_KERNEL_EXEC;
 	phys_addr_t pa_start = __pa_symbol(__entry_tramp_text_start);
+	int segment_size;
 
 	/* The trampoline is always mapped and can therefore be global */
 	pgprot_val(prot) &= ~PTE_NG;
@@ -551,6 +552,11 @@ static int __init map_entry_trampoline(void)
 	__create_pgd_mapping(tramp_pg_dir, pa_start, TRAMP_VALIAS, PAGE_SIZE,
 			     prot, pgd_pgtable_alloc, 0);
 
+	segment_size = __tramp_pgdir_segment_end - __tramp_pgdir_segment_start;
+	update_mapping_prot(__pa_symbol(__tramp_pgdir_segment_start),
+				(unsigned long)__tramp_pgdir_segment_start,
+				segment_size, PAGE_KERNEL_RO);
+
 	/* Map both the text and data into the kernel page table */
 	__set_fixmap(FIX_ENTRY_TRAMP_TEXT, pa_start, prot);
 	if (IS_ENABLED(CONFIG_RANDOMIZE_BASE)) {
-- 
2.17.0

^ permalink raw reply related

* [GIT PULL 0/7] perf/urgent fixes
From: Arnaldo Carvalho de Melo @ 2018-05-31 10:32 UTC (permalink / raw)
  To: linux-arm-kernel

Hi Ingo,

	Please consider pulling,

- Arnaldo

Test results at the end of this message, as usual.

The following changes since commit f3903c9161f0d636a7b0ff03841628928457e64c:

  Merge tag 'perf-urgent-for-mingo-4.17-20180514' of git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux into perf/urgent (2018-05-15 08:20:45 +0200)

are available in the Git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux.git tags/perf-urgent-for-mingo-4.17-20180531

for you to fetch changes up to 18a7057420f8b67f15d17087bf5c0863db752c8b:

  perf tools: Fix perf.data format description of NRCPUS header (2018-05-30 15:40:26 -0300)

----------------------------------------------------------------
perf/urgent fixes:

- Fix 'perf test Session topology' segfault on s390 (Thomas Richter)

- Fix NULL return handling in bpf__prepare_load() (YueHaibing)

- Fix indexing on Coresight ETM packet queue decoder (Mathieu Poirier)

- Fix perf.data format description of NRCPUS header (Arnaldo Carvalho de Melo)

- Update perf.data documentation section on cpu topology

- Handle uncore event aliases in small groups properly (Kan Liang)

- Add missing perf_sample.addr into python sample dictionary (Leo Yan)

Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>

----------------------------------------------------------------
Arnaldo Carvalho de Melo (1):
      perf tools: Fix perf.data format description of NRCPUS header

Kan Liang (1):
      perf parse-events: Handle uncore event aliases in small groups properly

Leo Yan (1):
      perf script python: Add addr into perf sample dict

Mathieu Poirier (1):
      perf cs-etm: Fix indexing for decoder packet queue

Thomas Richter (2):
      perf test: "Session topology" dumps core on s390
      perf data: Update documentation section on cpu topology

YueHaibing (1):
      perf bpf: Fix NULL return handling in bpf__prepare_load()

 tools/perf/Documentation/perf.data-file-format.txt |  10 +-
 tools/perf/tests/topology.c                        |  30 ++++-
 tools/perf/util/bpf-loader.c                       |   6 +-
 tools/perf/util/cs-etm-decoder/cs-etm-decoder.c    |  12 +-
 tools/perf/util/evsel.h                            |   1 +
 tools/perf/util/parse-events.c                     | 130 ++++++++++++++++++++-
 tools/perf/util/parse-events.h                     |   7 +-
 tools/perf/util/parse-events.y                     |   8 +-
 .../util/scripting-engines/trace-event-python.c    |   2 +
 9 files changed, 185 insertions(+), 21 deletions(-)

Test results:

The first ones are container (docker) based builds of tools/perf with
and without libelf support.  Where clang is available, it is also used
to build perf with/without libelf, and building with LIBCLANGLLVM=1
(built-in clang) with gcc and clang when clang and its devel libraries
are installed.

The objtool and samples/bpf/ builds are disabled now that I'm switching from
using the sources in a local volume to fetching them from a http server to
build it inside the container, to make it easier to build in a container cluster.
Those will come back later.

Several are cross builds, the ones with -x-ARCH and the android one, and those
may not have all the features built, due to lack of multi-arch devel packages,
available and being used so far on just a few, like
debian:experimental-x-{arm64,mipsel}.

The 'perf test' one will perform a variety of tests exercising
tools/perf/util/, tools/lib/{bpf,traceevent,etc}, as well as run perf commands
with a variety of command line event specifications to then intercept the
sys_perf_event syscall to check that the perf_event_attr fields are set up as
expected, among a variety of other unit tests.

Then there is the 'make -C tools/perf build-test' ones, that build tools/perf/
with a variety of feature sets, exercising the build with an incomplete set of
features as well as with a complete one. It is planned to have it run on each
of the containers mentioned above, using some container orchestration
infrastructure. Get in contact if interested in helping having this in place.

   1 alpine:3.4                    : Ok   gcc (Alpine 5.3.0) 5.3.0
   2 alpine:3.5                    : Ok   gcc (Alpine 6.2.1) 6.2.1 20160822
   3 alpine:3.6                    : Ok   gcc (Alpine 6.3.0) 6.3.0
   4 alpine:3.7                    : Ok   gcc (Alpine 6.4.0) 6.4.0
   5 alpine:edge                   : Ok   gcc (Alpine 6.4.0) 6.4.0
   6 amazonlinux:1                 : Ok   gcc (GCC) 4.8.5 20150623 (Red Hat 4.8.5-28)
   7 amazonlinux:2                 : Ok   gcc (GCC) 7.3.1 20180303 (Red Hat 7.3.1-5)
   8 android-ndk:r12b-arm          : Ok   arm-linux-androideabi-gcc (GCC) 4.9.x 20150123 (prerelease)
   9 android-ndk:r15c-arm          : Ok   arm-linux-androideabi-gcc (GCC) 4.9.x 20150123 (prerelease)
  10 centos:5                      : Ok   gcc (GCC) 4.1.2 20080704 (Red Hat 4.1.2-55)
  11 centos:6                      : Ok   gcc (GCC) 4.4.7 20120313 (Red Hat 4.4.7-18)
  12 centos:7                      : Ok   gcc (GCC) 4.8.5 20150623 (Red Hat 4.8.5-16)
  13 debian:7                      : Ok   gcc (Debian 4.7.2-5) 4.7.2
  14 debian:8                      : Ok   gcc (Debian 4.9.2-10+deb8u1) 4.9.2
  15 debian:9                      : Ok   gcc (Debian 6.3.0-18+deb9u1) 6.3.0 20170516
  16 debian:experimental           : Ok   gcc (Debian 7.3.0-19) 7.3.0
  17 debian:experimental-x-arm64   : Ok   aarch64-linux-gnu-gcc (Debian 7.3.0-19) 7.3.0
  18 debian:experimental-x-mips    : Ok   mips-linux-gnu-gcc (Debian 7.3.0-19) 7.3.0
  19 debian:experimental-x-mips64  : Ok   mips64-linux-gnuabi64-gcc (Debian 7.3.0-18) 7.3.0
  20 debian:experimental-x-mipsel  : Ok   mipsel-linux-gnu-gcc (Debian 7.3.0-19) 7.3.0
  21 fedora:20                     : Ok   gcc (GCC) 4.8.3 20140911 (Red Hat 4.8.3-7)
  22 fedora:21                     : Ok   gcc (GCC) 4.9.2 20150212 (Red Hat 4.9.2-6)
  23 fedora:22                     : Ok   gcc (GCC) 5.3.1 20160406 (Red Hat 5.3.1-6)
  24 fedora:23                     : Ok   gcc (GCC) 5.3.1 20160406 (Red Hat 5.3.1-6)
  25 fedora:24                     : Ok   gcc (GCC) 6.3.1 20161221 (Red Hat 6.3.1-1)
  26 fedora:24-x-ARC-uClibc        : Ok   arc-linux-gcc (ARCompact ISA Linux uClibc toolchain 2017.09-rc2) 7.1.1 20170710
  27 fedora:25                     : Ok   gcc (GCC) 6.4.1 20170727 (Red Hat 6.4.1-1)
  28 fedora:26                     : Ok   gcc (GCC) 7.3.1 20180130 (Red Hat 7.3.1-2)
  29 fedora:27                     : Ok   gcc (GCC) 7.3.1 20180303 (Red Hat 7.3.1-5)
  30 fedora:28                     : Ok   gcc (GCC) 8.1.1 20180502 (Red Hat 8.1.1-1)
  31 fedora:rawhide                : Ok   gcc (GCC) 8.0.1 20180324 (Red Hat 8.0.1-0.20)
  32 gentoo-stage3-amd64:latest    : Ok   gcc (Gentoo 6.4.0-r1 p1.3) 6.4.0
  33 mageia:5                      : Ok   gcc (GCC) 4.9.2
  34 mageia:6                      : Ok   gcc (Mageia 5.5.0-1.mga6) 5.5.0
  35 opensuse:42.1                 : Ok   gcc (SUSE Linux) 4.8.5
  36 opensuse:42.2                 : Ok   gcc (SUSE Linux) 4.8.5
  37 opensuse:42.3                 : Ok   gcc (SUSE Linux) 4.8.5
  38 opensuse:tumbleweed           : Ok   gcc (SUSE Linux) 7.3.1 20180323 [gcc-7-branch revision 258812]
  39 oraclelinux:6                 : Ok   gcc (GCC) 4.4.7 20120313 (Red Hat 4.4.7-18.0.7)
  40 oraclelinux:7                 : Ok   gcc (GCC) 4.8.5 20150623 (Red Hat 4.8.5-28.0.1)
  41 ubuntu:12.04.5                : Ok   gcc (Ubuntu/Linaro 4.6.3-1ubuntu5) 4.6.3
  42 ubuntu:14.04.4                : Ok   gcc (Ubuntu 4.8.4-2ubuntu1~14.04.3) 4.8.4
  43 ubuntu:14.04.4-x-linaro-arm64 : Ok   aarch64-linux-gnu-gcc (Linaro GCC 5.5-2017.10) 5.5.0
  44 ubuntu:16.04                  : Ok   gcc (Ubuntu 5.4.0-6ubuntu1~16.04.9) 5.4.0 20160609
  45 ubuntu:16.04-x-arm            : Ok   arm-linux-gnueabihf-gcc (Ubuntu/Linaro 5.4.0-6ubuntu1~16.04.9) 5.4.0 20160609
  46 ubuntu:16.04-x-arm64          : Ok   aarch64-linux-gnu-gcc (Ubuntu/Linaro 5.4.0-6ubuntu1~16.04.9) 5.4.0 20160609
  47 ubuntu:16.04-x-powerpc        : Ok   powerpc-linux-gnu-gcc (Ubuntu 5.4.0-6ubuntu1~16.04.9) 5.4.0 20160609
  48 ubuntu:16.04-x-powerpc64      : Ok   powerpc64-linux-gnu-gcc (Ubuntu/IBM 5.4.0-6ubuntu1~16.04.9) 5.4.0 20160609
  49 ubuntu:16.04-x-powerpc64el    : Ok   powerpc64le-linux-gnu-gcc (Ubuntu/IBM 5.4.0-6ubuntu1~16.04.9) 5.4.0 20160609
  50 ubuntu:16.04-x-s390           : Ok   s390x-linux-gnu-gcc (Ubuntu 5.4.0-6ubuntu1~16.04.9) 5.4.0 20160609
  51 ubuntu:16.10                  : Ok   gcc (Ubuntu 6.2.0-5ubuntu12) 6.2.0 20161005
  52 ubuntu:17.04                  : Ok   gcc (Ubuntu 6.3.0-12ubuntu2) 6.3.0 20170406
  53 ubuntu:17.10                  : Ok   gcc (Ubuntu 7.2.0-8ubuntu3.2) 7.2.0
  54 ubuntu:18.04                  : Ok   gcc (Ubuntu 7.3.0-16ubuntu3) 7.3.0

  # git log --oneline -1
  18a7057420f8 (HEAD -> perf/urgent) perf tools: Fix perf.data format description of NRCPUS header
  # perf --version
  perf version 4.17.rc5.g18a7057
  # uname -a
  Linux jouet 4.17.0-rc5 #21 SMP Mon May 14 15:35:35 -03 2018 x86_64 x86_64 x86_64 GNU/Linux
  # perf test
   1: vmlinux symtab matches kallsyms                       : Ok
   2: Detect openat syscall event                           : Ok
   3: Detect openat syscall event on all cpus               : Ok
   4: Read samples using the mmap interface                 : Ok
   5: Test data source output                               : Ok
   6: Parse event definition strings                        : Ok
   7: Simple expression parser                              : Ok
   8: PERF_RECORD_* events & perf_sample fields             : Ok
   9: Parse perf pmu format                                 : Ok
  10: DSO data read                                         : Ok
  11: DSO data cache                                        : Ok
  12: DSO data reopen                                       : Ok
  13: Roundtrip evsel->name                                 : Ok
  14: Parse sched tracepoints fields                        : Ok
  15: syscalls:sys_enter_openat event fields                : Ok
  16: Setup struct perf_event_attr                          : Ok
  17: Match and link multiple hists                         : Ok
  18: 'import perf' in python                               : Ok
  19: Breakpoint overflow signal handler                    : Ok
  20: Breakpoint overflow sampling                          : Ok
  21: Breakpoint accounting                                 : Ok
  22: Number of exit events of a simple workload            : Ok
  23: Software clock events period values                   : Ok
  24: Object code reading                                   : Ok
  25: Sample parsing                                        : Ok
  26: Use a dummy software event to keep tracking           : Ok
  27: Parse with no sample_id_all bit set                   : Ok
  28: Filter hist entries                                   : Ok
  29: Lookup mmap thread                                    : Ok
  30: Share thread mg                                       : Ok
  31: Sort output of hist entries                           : Ok
  32: Cumulate child hist entries                           : Ok
  33: Track with sched_switch                               : Ok
  34: Filter fds with revents mask in a fdarray             : Ok
  35: Add fd to a fdarray, making it autogrow               : Ok
  36: kmod_path__parse                                      : Ok
  37: Thread map                                            : Ok
  38: LLVM search and compile                               :
  38.1: Basic BPF llvm compile                              : Ok
  38.2: kbuild searching                                    : Ok
  38.3: Compile source for BPF prologue generation          : Ok
  38.4: Compile source for BPF relocation                   : Ok
  39: Session topology                                      : Ok
  40: BPF filter                                            :
  40.1: Basic BPF filtering                                 : Ok
  40.2: BPF pinning                                         : Ok
  40.3: BPF prologue generation                             : Ok
  40.4: BPF relocation checker                              : Ok
  41: Synthesize thread map                                 : Ok
  42: Remove thread map                                     : Ok
  43: Synthesize cpu map                                    : Ok
  44: Synthesize stat config                                : Ok
  45: Synthesize stat                                       : Ok
  46: Synthesize stat round                                 : Ok
  47: Synthesize attr update                                : Ok
  48: Event times                                           : Ok
  49: Read backward ring buffer                             : Ok
  50: Print cpu map                                         : Ok
  51: Probe SDT events                                      : Ok
  52: is_printable_array                                    : Ok
  53: Print bitmap                                          : Ok
  54: perf hooks                                            : Ok
  55: builtin clang support                                 : Skip (not compiled in)
  56: unit_number__scnprintf                                : Ok
  57: mem2node                                              : Ok
  58: x86 rdpmc                                             : Ok
  59: Convert perf time to TSC                              : Ok
  60: DWARF unwind                                          : Ok
  61: x86 instruction decoder - new instructions            : Ok
  62: Use vfs_getname probe to get syscall args filenames   : Ok
  63: Check open filename arg using perf trace + vfs_getname: Ok
  64: probe libc's inet_pton & backtrace it with ping       : Ok
  65: Add vfs_getname probe to get syscall args filenames   : Ok
  #

  $ make -C tools/perf build-test
  make: Entering directory '/home/acme/git/perf/tools/perf'
  - tarpkg: ./tests/perf-targz-src-pkg .
                   make_pure_O: make
                 make_static_O: make LDFLAGS=-static
           make_no_libpython_O: make NO_LIBPYTHON=1
                    make_doc_O: make doc
  make_no_libdw_dwarf_unwind_O: make NO_LIBDW_DWARF_UNWIND=1
              make_no_libbpf_O: make NO_LIBBPF=1
           make_no_backtrace_O: make NO_BACKTRACE=1
            make_install_bin_O: make install-bin
            make_no_auxtrace_O: make NO_AUXTRACE=1
                  make_no_ui_O: make NO_NEWT=1 NO_SLANG=1 NO_GTK2=1
                   make_tags_O: make tags
         make_install_prefix_O: make install prefix=/tmp/krava
              make_clean_all_O: make clean all
             make_no_libperl_O: make NO_LIBPERL=1
             make_util_map_o_O: make util/map.o
        make_with_babeltrace_O: make LIBBABELTRACE=1
                 make_perf_o_O: make perf.o
           make_no_libunwind_O: make NO_LIBUNWIND=1
                make_no_newt_O: make NO_NEWT=1
            make_no_libaudit_O: make NO_LIBAUDIT=1
                make_no_gtk2_O: make NO_GTK2=1
                make_minimal_O: make NO_LIBPERL=1 NO_LIBPYTHON=1 NO_NEWT=1 NO_GTK2=1 NO_DEMANGLE=1 NO_LIBELF=1 NO_LIBUNWIND=1 NO_BACKTRACE=1 NO_LIBNUMA=1 NO_LIBAUDIT=1 NO_LIBBIONIC=1 NO_LIBDW_DWARF_UNWIND=1 NO_AUXTRACE=1 NO_LIBBPF=1 NO_LIBCRYPTO=1 NO_SDT=1 NO_JVMTI=1
             make_no_scripts_O: make NO_LIBPYTHON=1 NO_LIBPERL=1
           make_no_libbionic_O: make NO_LIBBIONIC=1
         make_with_clangllvm_O: make LIBCLANGLLVM=1
   make_install_prefix_slash_O: make install prefix=/tmp/krava/
             make_no_libnuma_O: make NO_LIBNUMA=1
               make_no_slang_O: make NO_SLANG=1
                make_install_O: make install
              make_no_libelf_O: make NO_LIBELF=1
       make_util_pmu_bison_o_O: make util/pmu-bison.o
                   make_help_O: make help
                  make_debug_O: make DEBUG=1
            make_no_demangle_O: make NO_DEMANGLE=1
  OK
  make: Leaving directory '/home/acme/git/perf/tools/perf'
  $

^ permalink raw reply

* [PATCH 4/7] perf cs-etm: Fix indexing for decoder packet queue
From: Arnaldo Carvalho de Melo @ 2018-05-31 10:32 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <20180531103220.24684-1-acme@kernel.org>

From: Mathieu Poirier <mathieu.poirier@linaro.org>

The tail of a queue is supposed to be pointing to the next available
slot in a queue.  In this implementation the tail is incremented before
it is used and as such points to the last used element, something that
has the immense advantage of centralizing tail management at a single
location and eliminating a lot of redundant code.

But this needs to be taken into consideration on the dequeueing side
where the head also needs to be incremented before it is used, or the
first available element of the queue will be skipped.

Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
Tested-by: Leo Yan <leo.yan@linaro.org>
Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Cc: Jiri Olsa <jolsa@redhat.com>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Robert Walker <robert.walker@arm.com>
Cc: linux-arm-kernel at lists.infradead.org
Link: http://lkml.kernel.org/r/1527289854-10755-1-git-send-email-mathieu.poirier at linaro.org
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
---
 tools/perf/util/cs-etm-decoder/cs-etm-decoder.c | 12 ++++++++++--
 1 file changed, 10 insertions(+), 2 deletions(-)

diff --git a/tools/perf/util/cs-etm-decoder/cs-etm-decoder.c b/tools/perf/util/cs-etm-decoder/cs-etm-decoder.c
index c8b98fa22997..4d5fc374e730 100644
--- a/tools/perf/util/cs-etm-decoder/cs-etm-decoder.c
+++ b/tools/perf/util/cs-etm-decoder/cs-etm-decoder.c
@@ -96,11 +96,19 @@ int cs_etm_decoder__get_packet(struct cs_etm_decoder *decoder,
 	/* Nothing to do, might as well just return */
 	if (decoder->packet_count == 0)
 		return 0;
+	/*
+	 * The queueing process in function cs_etm_decoder__buffer_packet()
+	 * increments the tail *before* using it.  This is somewhat counter
+	 * intuitive but it has the advantage of centralizing tail management
+	 * at a single location.  Because of that we need to follow the same
+	 * heuristic with the head, i.e we increment it before using its
+	 * value.  Otherwise the first element of the packet queue is not
+	 * used.
+	 */
+	decoder->head = (decoder->head + 1) & (MAX_BUFFER - 1);
 
 	*packet = decoder->packet_buffer[decoder->head];
 
-	decoder->head = (decoder->head + 1) & (MAX_BUFFER - 1);
-
 	decoder->packet_count--;
 
 	return 1;
-- 
2.14.3

^ permalink raw reply related

* [PATCH 6/7] perf script python: Add addr into perf sample dict
From: Arnaldo Carvalho de Melo @ 2018-05-31 10:32 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <20180531103220.24684-1-acme@kernel.org>

From: Leo Yan <leo.yan@linaro.org>

ARM CoreSight auxtrace uses 'sample->addr' to record the target address
for branch instructions, so the data of 'sample->addr' is required for
tracing data analysis.

This commit collects data of 'sample->addr' into perf sample dict,
finally can be used for python script for parsing event.

Signed-off-by: Leo Yan <leo.yan@linaro.org>
Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Cc: Jiri Olsa <jolsa@redhat.com>
Cc: Jonathan Corbet <corbet@lwn.net>
Cc: Mathieu Poirier <mathieu.poirier@linaro.org>
Cc: Mike Leach <mike.leach@linaro.org>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Robert Walker <robert.walker@arm.com>
Cc: Tor Jeremiassen <tor@ti.com>
Cc: coresight at lists.linaro.org
Cc: kim.phillips at arm.co
Cc: linux-arm-kernel at lists.infradead.org
Cc: linux-doc at vger.kernel.org
Link: http://lkml.kernel.org/r/1527497103-3593-3-git-send-email-leo.yan at linaro.org
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
---
 tools/perf/util/scripting-engines/trace-event-python.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/tools/perf/util/scripting-engines/trace-event-python.c b/tools/perf/util/scripting-engines/trace-event-python.c
index 10dd5fce082b..7f8afacd08ee 100644
--- a/tools/perf/util/scripting-engines/trace-event-python.c
+++ b/tools/perf/util/scripting-engines/trace-event-python.c
@@ -531,6 +531,8 @@ static PyObject *get_perf_sample_dict(struct perf_sample *sample,
 			PyLong_FromUnsignedLongLong(sample->period));
 	pydict_set_item_string_decref(dict_sample, "phys_addr",
 			PyLong_FromUnsignedLongLong(sample->phys_addr));
+	pydict_set_item_string_decref(dict_sample, "addr",
+			PyLong_FromUnsignedLongLong(sample->addr));
 	set_sample_read_in_dict(dict_sample, sample, evsel);
 	pydict_set_item_string_decref(dict, "sample", dict_sample);
 
-- 
2.14.3

^ permalink raw reply related

* [PATCH v4 0/2] regulator: add QCOM RPMh regulator driver
From: Mark Brown @ 2018-05-31 10:38 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <da40510b-443d-d8fd-7285-c6e7eff45dc6@codeaurora.org>

On Wed, May 30, 2018 at 05:11:54PM -0700, David Collins wrote:

> I'll split up the patches so that reviewing is easier.  For the base
> patch, would you prefer that I remove *all* mode support (handled by
> generic regulator framework DT properties) or only remove the special
> purpose drms mode handling support (i.e. qcom,regulator-drms-modes and
> qcom,drms-mode-max-microamps)?

Standard operations should be fine, just weird custom stuff that's been
causing issues.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20180531/cc95ff7c/attachment.sig>

^ permalink raw reply

* [GIT PULL 0/7] perf/urgent fixes
From: Ingo Molnar @ 2018-05-31 10:40 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <20180531103220.24684-1-acme@kernel.org>


* Arnaldo Carvalho de Melo <acme@kernel.org> wrote:

> Hi Ingo,
> 
> 	Please consider pulling,
> 
> - Arnaldo
> 
> Test results at the end of this message, as usual.
> 
> The following changes since commit f3903c9161f0d636a7b0ff03841628928457e64c:
> 
>   Merge tag 'perf-urgent-for-mingo-4.17-20180514' of git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux into perf/urgent (2018-05-15 08:20:45 +0200)
> 
> are available in the Git repository at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux.git tags/perf-urgent-for-mingo-4.17-20180531
> 
> for you to fetch changes up to 18a7057420f8b67f15d17087bf5c0863db752c8b:
> 
>   perf tools: Fix perf.data format description of NRCPUS header (2018-05-30 15:40:26 -0300)
> 
> ----------------------------------------------------------------
> perf/urgent fixes:
> 
> - Fix 'perf test Session topology' segfault on s390 (Thomas Richter)
> 
> - Fix NULL return handling in bpf__prepare_load() (YueHaibing)
> 
> - Fix indexing on Coresight ETM packet queue decoder (Mathieu Poirier)
> 
> - Fix perf.data format description of NRCPUS header (Arnaldo Carvalho de Melo)
> 
> - Update perf.data documentation section on cpu topology
> 
> - Handle uncore event aliases in small groups properly (Kan Liang)
> 
> - Add missing perf_sample.addr into python sample dictionary (Leo Yan)
> 
> Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
> 
> ----------------------------------------------------------------
> Arnaldo Carvalho de Melo (1):
>       perf tools: Fix perf.data format description of NRCPUS header
> 
> Kan Liang (1):
>       perf parse-events: Handle uncore event aliases in small groups properly
> 
> Leo Yan (1):
>       perf script python: Add addr into perf sample dict
> 
> Mathieu Poirier (1):
>       perf cs-etm: Fix indexing for decoder packet queue
> 
> Thomas Richter (2):
>       perf test: "Session topology" dumps core on s390
>       perf data: Update documentation section on cpu topology
> 
> YueHaibing (1):
>       perf bpf: Fix NULL return handling in bpf__prepare_load()
> 
>  tools/perf/Documentation/perf.data-file-format.txt |  10 +-
>  tools/perf/tests/topology.c                        |  30 ++++-
>  tools/perf/util/bpf-loader.c                       |   6 +-
>  tools/perf/util/cs-etm-decoder/cs-etm-decoder.c    |  12 +-
>  tools/perf/util/evsel.h                            |   1 +
>  tools/perf/util/parse-events.c                     | 130 ++++++++++++++++++++-
>  tools/perf/util/parse-events.h                     |   7 +-
>  tools/perf/util/parse-events.y                     |   8 +-
>  .../util/scripting-engines/trace-event-python.c    |   2 +
>  9 files changed, 185 insertions(+), 21 deletions(-)

Pulled, thanks a lot Arnaldo!

	Ingo

^ permalink raw reply

* [PATCH v2 8/9] PM / Domains: Add support for multi PM domains per device to genpd
From: Ulf Hansson @ 2018-05-31 10:44 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <e313f870-ef27-7721-9395-31671f00ef4a@nvidia.com>

On 31 May 2018 at 10:03, Jon Hunter <jonathanh@nvidia.com> wrote:
>
> On 31/05/18 07:17, Ulf Hansson wrote:
>> [...]
>>
>>>> +/**
>>>> + * genpd_dev_pm_attach_by_id() - Attach a device to one of its PM domain.
>>>> + * @dev: Device to attach.
>>>
>>> Can you update the description of the above as well?
>>
>> Yes, like below?
>>
>> genpd_dev_pm_attach_by_id() - Associate a device with one of its PM domains.
>> @dev: The device used to lookup the PM domain.
>
> Yes perfect.

I assume I can consider this as an ack and tested by tag, both for
patch 8 and 9?

Kind regards
Uffe

^ permalink raw reply

* [PATCH v2 0/9] PM / Domains: Add support for multi PM domains per device
From: Ulf Hansson @ 2018-05-31 10:47 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <20180531091410.fl5f42zmyqi6zj5a@vireshk-i7>

On 31 May 2018 at 11:14, Viresh Kumar <viresh.kumar@linaro.org> wrote:
> On 29-05-18, 12:04, Ulf Hansson wrote:
>> Changes in v2:
>>       - Addressed comments from Geert around DT doc.
>>       - Addressed comments from Jon around clarification of how to use this
>>       and changes to returned error codes.
>>       - Fixed build error in case CONFIG_PM was unset.
>>
>> There are devices that are partitioned across multiple PM domains. Currently
>> these can't be supported well by the available PM infrastructures we have in
>> the kernel. This series is an attempt to address this.
>>
>> The interesting parts happens from patch 5 an onwards, including a minor DT
>> update to the existing power-domain bindings, the 4 earlier are just trivial
>> clean-ups of some related code in genpd, which I happened to stumble over.
>>
>> Some additional background:
>>
>> One existing case where devices are partitioned across multiple PM domains, is
>> the Nvida Tegra 124/210 X-USB subsystem. A while ago Jon Hunter (Nvidia) sent a
>> series, trying to address these issues, however this is a new approach, while
>> it re-uses the same concepts from DT point of view.
>>
>> The Tegra 124/210 X-USB subsystem contains of a host controller and a device
>> controller. Each controller have its own independent PM domain, but are being
>> partitioned across another shared PM domain for the USB super-speed logic.
>>
>> Currently to make the drivers work, either the related PM domains needs to stay
>> powered on always or the PM domain topology needs to be in-correctly modelled
>> through sub-domains. In both cases PM domains may be powered on while they
>> don't need to be, so in the end this means - wasting power -.
>>
>> As stated above, this series intends to address these problem from a PM
>> infrastructure point of view. More details are available in each changelog.
>>
>> It should be noted that this series has been tested on HW, however only by using
>> a home-cooked test PM domain driver for genpd and together with a test driver.
>> This allowed me to play with PM domain (genpd), runtime PM and device links.
>>
>> Any further deployment for real use cases are greatly appreciated. I am happy to
>> to help, if needed!
>
> Reviewed-by: Viresh Kumar <viresh.kumar@linaro.org>

Thanks!

Kind regards
Uffe

^ permalink raw reply

* [PATCH v2 8/9] PM / Domains: Add support for multi PM domains per device to genpd
From: Jon Hunter @ 2018-05-31 10:48 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <CAPDyKFrtSGF79pFf-sx41ru_EVLk3BMg_f_5rK64k==dW=OXPA@mail.gmail.com>


On 31/05/18 11:44, Ulf Hansson wrote:
> On 31 May 2018 at 10:03, Jon Hunter <jonathanh@nvidia.com> wrote:
>>
>> On 31/05/18 07:17, Ulf Hansson wrote:
>>> [...]
>>>
>>>>> +/**
>>>>> + * genpd_dev_pm_attach_by_id() - Attach a device to one of its PM domain.
>>>>> + * @dev: Device to attach.
>>>>
>>>> Can you update the description of the above as well?
>>>
>>> Yes, like below?
>>>
>>> genpd_dev_pm_attach_by_id() - Associate a device with one of its PM domains.
>>> @dev: The device used to lookup the PM domain.
>>
>> Yes perfect.
> 
> I assume I can consider this as an ack and tested by tag, both for
> patch 8 and 9?

Yes you can.

Cheers
Jon

-- 
nvpublic

^ permalink raw reply

* [PATCH v1 1/2] ACPI / APEI: Add SEI notification type support for ARMv8
From: Mark Rutland @ 2018-05-31 10:52 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1527770506-8076-2-git-send-email-gengdongjiu@huawei.com>

On Thu, May 31, 2018 at 08:41:45PM +0800, Dongjiu Geng wrote:
> +#ifdef CONFIG_ACPI_APEI_SEI
> +static LIST_HEAD(ghes_sei);
> +
> +/*
> + * Return 0 only if one of the SEI error sources successfully reported an error
> + * record sent from the firmware.
> + */
> +int ghes_notify_sei(void)
> +{
> +	struct ghes *ghes;
> +	int ret = -ENOENT;
> +
> +	rcu_read_lock();
> +	list_for_each_entry_rcu(ghes, &ghes_sei, list) {
> +		if (!ghes_proc(ghes))
> +			ret = 0;
> +	}
> +	rcu_read_unlock();
> +	return ret;
> +}
> +
> +static void ghes_sei_add(struct ghes *ghes)
> +{
> +	mutex_lock(&ghes_list_mutex);
> +	list_add_rcu(&ghes->list, &ghes_sei);
> +	mutex_unlock(&ghes_list_mutex);
> +}
> +
> +static void ghes_sei_remove(struct ghes *ghes)
> +{
> +	mutex_lock(&ghes_list_mutex);
> +	list_del_rcu(&ghes->list);
> +	mutex_unlock(&ghes_list_mutex);
> +	synchronize_rcu();
> +}
> +#else /* CONFIG_ACPI_APEI_SEI */
> +static inline void ghes_sei_add(struct ghes *ghes) { }
> +static inline void ghes_sei_remove(struct ghes *ghes) { }
> +#endif /* CONFIG_ACPI_APEI_SEI */
> +
>  #ifdef CONFIG_HAVE_ACPI_APEI_NMI
>  /*

> index 8feb0c8..9ba59e2 100644
> --- a/include/acpi/ghes.h
> +++ b/include/acpi/ghes.h
> @@ -120,5 +120,6 @@ static inline void *acpi_hest_get_next(struct acpi_hest_generic_data *gdata)
>  	     section = acpi_hest_get_next(section))
>  
>  int ghes_notify_sea(void);
> +int ghes_notify_sei(void);

It would be nice to have a stub definition when !CONFIG_ACPI_APEI_SEI,
e.g.

#ifdef CONFIG_ACPI_APEI_SEI
int ghes_notify_sei(void);
#else
static in int ghes_notify_sei(void) { return -ENOENT; }
#endif

... as callers could simply call this without additional checks.

As a cleanup, similar would be nice for ghes_notify_sea() with
CONFIG_ACPI_APEI_SEA.

Thanks,
Mark.

^ permalink raw reply

* [PATCH v3 0/5] PM / Domains: Add support for multi PM domains per device
From: Ulf Hansson @ 2018-05-31 10:59 UTC (permalink / raw)
  To: linux-arm-kernel

Changes in v3:
	- Drop patch 1->4 as they have already been applied.
	- Collected tags, for tests and reviews.
	- Minor update to function descriptions in patch 4 (earlier 8) and 5
	(earlier9).
	- Note, because of the minor changes, no history is provided per patch.

Changes in v2:
	- Addressed comments from Geert around DT doc.
	- Addressed comments from Jon around clarification of how to use this
	and changes to returned error codes.
	- Fixed build error in case CONFIG_PM was unset.

There are devices that are partitioned across multiple PM domains. Currently
these can't be supported well by the available PM infrastructures we have in
the kernel. This series is an attempt to address this.

One existing case where devices are partitioned across multiple PM domains, is
the Nvida Tegra 124/210 X-USB subsystem. A while ago Jon Hunter (Nvidia) sent a
series, trying to address these issues, however this is a new approach, while
it re-uses the same concepts from DT point of view.

The Tegra 124/210 X-USB subsystem contains of a host controller and a device
controller. Each controller have its own independent PM domain, but are being
partitioned across another shared PM domain for the USB super-speed logic.

Currently to make the drivers work, either the related PM domains needs to stay
powered on always or the PM domain topology needs to be in-correctly modelled
through sub-domains. In both cases PM domains may be powered on while they
don't need to be, so in the end this means - wasting power -.

As stated above, this series intends to address these problem from a PM
infrastructure point of view. More details are available in each changelog.

Kind regards
Ulf Hansson

Ulf Hansson (5):
  PM / Domains: dt: Allow power-domain property to be a list of
    specifiers
  PM / Domains: Don't attach devices in genpd with multi PM domains
  PM / Domains: Split genpd_dev_pm_attach()
  PM / Domains: Add support for multi PM domains per device to genpd
  PM / Domains: Add dev_pm_domain_attach_by_id() to manage multi PM
    domains

 .../bindings/power/power_domain.txt           |  19 ++-
 drivers/base/power/common.c                   |  43 +++++-
 drivers/base/power/domain.c                   | 134 +++++++++++++++---
 include/linux/pm_domain.h                     |  15 ++
 4 files changed, 183 insertions(+), 28 deletions(-)

-- 
2.17.0

^ permalink raw reply

* [PATCH v3 1/5] PM / Domains: dt: Allow power-domain property to be a list of specifiers
From: Ulf Hansson @ 2018-05-31 10:59 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <20180531105959.14843-1-ulf.hansson@linaro.org>

To be able to describe topologies where devices are partitioned across
multiple power domains, let's extend the power-domain property to allow
being a list of PM domain specifiers.

Cc: Rob Herring <robh+dt@kernel.org>
Cc: devicetree at vger.kernel.org
Suggested-by: Jon Hunter <jonathanh@nvidia.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Reviewed-by: Rob Herring <robh@kernel.org>
Reviewed-by: Viresh Kumar <viresh.kumar@linaro.org>
---
 .../bindings/power/power_domain.txt           | 19 ++++++++++++++-----
 1 file changed, 14 insertions(+), 5 deletions(-)

diff --git a/Documentation/devicetree/bindings/power/power_domain.txt b/Documentation/devicetree/bindings/power/power_domain.txt
index 4733f76cbe48..9b387f861aed 100644
--- a/Documentation/devicetree/bindings/power/power_domain.txt
+++ b/Documentation/devicetree/bindings/power/power_domain.txt
@@ -111,8 +111,8 @@ Example 3:
 ==PM domain consumers==
 
 Required properties:
- - power-domains : A phandle and PM domain specifier as defined by bindings of
-                   the power controller specified by phandle.
+ - power-domains : A list of PM domain specifiers, as defined by bindings of
+		the power controller that is the PM domain provider.
 
 Example:
 
@@ -122,9 +122,18 @@ Example:
 		power-domains = <&power 0>;
 	};
 
-The node above defines a typical PM domain consumer device, which is located
-inside a PM domain with index 0 of a power controller represented by a node
-with the label "power".
+	leaky-device at 12351000 {
+		compatible = "foo,i-leak-current";
+		reg = <0x12351000 0x1000>;
+		power-domains = <&power 0>, <&power 1> ;
+	};
+
+The first example above defines a typical PM domain consumer device, which is
+located inside a PM domain with index 0 of a power controller represented by a
+node with the label "power".
+In the second example the consumer device are partitioned across two PM domains,
+the first with index 0 and the second with index 1, of a power controller that
+is represented by a node with the label "power.
 
 Optional properties:
 - required-opps: This contains phandle to an OPP node in another device's OPP
-- 
2.17.0

^ permalink raw reply related

* [PATCH v3 2/5] PM / Domains: Don't attach devices in genpd with multi PM domains
From: Ulf Hansson @ 2018-05-31 10:59 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <20180531105959.14843-1-ulf.hansson@linaro.org>

The power-domain DT property may now contain a list of PM domain
specifiers, which represents that a device are partitioned across multiple
PM domains. This leads to a new situation in genpd_dev_pm_attach(), as only
one PM domain can be attached per device.

To remain things simple for the most common configuration, when a single PM
domain is used, let's treat the multiple PM domain case as being specific.

In other words, let's change genpd_dev_pm_attach() to check for multiple PM
domains and prevent it from attach any PM domain for this case. Instead,
leave this to be managed separately, from following changes to genpd.

Cc: Rob Herring <robh+dt@kernel.org>
Cc: devicetree at vger.kernel.org
Suggested-by: Jon Hunter <jonathanh@nvidia.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Acked-by: Jon Hunter <jonathanh@nvidia.com>
Tested-by: Jon Hunter <jonathanh@nvidia.com>
Reviewed-by: Viresh Kumar <viresh.kumar@linaro.org>
---
 drivers/base/power/domain.c | 18 +++++++++++++-----
 1 file changed, 13 insertions(+), 5 deletions(-)

diff --git a/drivers/base/power/domain.c b/drivers/base/power/domain.c
index 6f403d6fccb2..908c44779ae7 100644
--- a/drivers/base/power/domain.c
+++ b/drivers/base/power/domain.c
@@ -2229,10 +2229,10 @@ static void genpd_dev_pm_sync(struct device *dev)
  * attaches the device to retrieved pm_domain ops.
  *
  * Returns 1 on successfully attached PM domain, 0 when the device don't need a
- * PM domain or a negative error code in case of failures. Note that if a
- * power-domain exists for the device, but it cannot be found or turned on,
- * then return -EPROBE_DEFER to ensure that the device is not probed and to
- * re-try again later.
+ * PM domain or when multiple power-domains exists for it, else a negative error
+ * code. Note that if a power-domain exists for the device, but it cannot be
+ * found or turned on, then return -EPROBE_DEFER to ensure that the device is
+ * not probed and to re-try again later.
  */
 int genpd_dev_pm_attach(struct device *dev)
 {
@@ -2243,10 +2243,18 @@ int genpd_dev_pm_attach(struct device *dev)
 	if (!dev->of_node)
 		return 0;
 
+	/*
+	 * Devices with multiple PM domains must be attached separately, as we
+	 * can only attach one PM domain per device.
+	 */
+	if (of_count_phandle_with_args(dev->of_node, "power-domains",
+				       "#power-domain-cells") != 1)
+		return 0;
+
 	ret = of_parse_phandle_with_args(dev->of_node, "power-domains",
 					"#power-domain-cells", 0, &pd_args);
 	if (ret < 0)
-		return 0;
+		return ret;
 
 	mutex_lock(&gpd_list_lock);
 	pd = genpd_get_from_provider(&pd_args);
-- 
2.17.0

^ permalink raw reply related

* [PATCH v3 3/5] PM / Domains: Split genpd_dev_pm_attach()
From: Ulf Hansson @ 2018-05-31 10:59 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <20180531105959.14843-1-ulf.hansson@linaro.org>

To extend genpd to deal with allowing multiple PM domains per device, some
of the code in genpd_dev_pm_attach() can be re-used. Let's prepare for this
by moving some of the code into a sub-function.

Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Acked-by: Jon Hunter <jonathanh@nvidia.com>
Tested-by: Jon Hunter <jonathanh@nvidia.com>
Reviewed-by: Viresh Kumar <viresh.kumar@linaro.org>
---
 drivers/base/power/domain.c | 60 ++++++++++++++++++++-----------------
 1 file changed, 33 insertions(+), 27 deletions(-)

diff --git a/drivers/base/power/domain.c b/drivers/base/power/domain.c
index 908c44779ae7..b1fcbf917974 100644
--- a/drivers/base/power/domain.c
+++ b/drivers/base/power/domain.c
@@ -2221,38 +2221,15 @@ static void genpd_dev_pm_sync(struct device *dev)
 	genpd_queue_power_off_work(pd);
 }
 
-/**
- * genpd_dev_pm_attach - Attach a device to its PM domain using DT.
- * @dev: Device to attach.
- *
- * Parse device's OF node to find a PM domain specifier. If such is found,
- * attaches the device to retrieved pm_domain ops.
- *
- * Returns 1 on successfully attached PM domain, 0 when the device don't need a
- * PM domain or when multiple power-domains exists for it, else a negative error
- * code. Note that if a power-domain exists for the device, but it cannot be
- * found or turned on, then return -EPROBE_DEFER to ensure that the device is
- * not probed and to re-try again later.
- */
-int genpd_dev_pm_attach(struct device *dev)
+static int __genpd_dev_pm_attach(struct device *dev, struct device_node *np,
+				 unsigned int index)
 {
 	struct of_phandle_args pd_args;
 	struct generic_pm_domain *pd;
 	int ret;
 
-	if (!dev->of_node)
-		return 0;
-
-	/*
-	 * Devices with multiple PM domains must be attached separately, as we
-	 * can only attach one PM domain per device.
-	 */
-	if (of_count_phandle_with_args(dev->of_node, "power-domains",
-				       "#power-domain-cells") != 1)
-		return 0;
-
-	ret = of_parse_phandle_with_args(dev->of_node, "power-domains",
-					"#power-domain-cells", 0, &pd_args);
+	ret = of_parse_phandle_with_args(np, "power-domains",
+				"#power-domain-cells", index, &pd_args);
 	if (ret < 0)
 		return ret;
 
@@ -2290,6 +2267,35 @@ int genpd_dev_pm_attach(struct device *dev)
 
 	return ret ? -EPROBE_DEFER : 1;
 }
+
+/**
+ * genpd_dev_pm_attach - Attach a device to its PM domain using DT.
+ * @dev: Device to attach.
+ *
+ * Parse device's OF node to find a PM domain specifier. If such is found,
+ * attaches the device to retrieved pm_domain ops.
+ *
+ * Returns 1 on successfully attached PM domain, 0 when the device don't need a
+ * PM domain or when multiple power-domains exists for it, else a negative error
+ * code. Note that if a power-domain exists for the device, but it cannot be
+ * found or turned on, then return -EPROBE_DEFER to ensure that the device is
+ * not probed and to re-try again later.
+ */
+int genpd_dev_pm_attach(struct device *dev)
+{
+	if (!dev->of_node)
+		return 0;
+
+	/*
+	 * Devices with multiple PM domains must be attached separately, as we
+	 * can only attach one PM domain per device.
+	 */
+	if (of_count_phandle_with_args(dev->of_node, "power-domains",
+				       "#power-domain-cells") != 1)
+		return 0;
+
+	return __genpd_dev_pm_attach(dev, dev->of_node, 0);
+}
 EXPORT_SYMBOL_GPL(genpd_dev_pm_attach);
 
 static const struct of_device_id idle_state_match[] = {
-- 
2.17.0

^ permalink raw reply related

* [PATCH v3 4/5] PM / Domains: Add support for multi PM domains per device to genpd
From: Ulf Hansson @ 2018-05-31 10:59 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <20180531105959.14843-1-ulf.hansson@linaro.org>

To support devices being partitioned across multiple PM domains, let's
begin with extending genpd to cope with these kind of configurations.

Therefore, add a new exported function genpd_dev_pm_attach_by_id(), which
is similar to the existing genpd_dev_pm_attach(), but with the difference
that it allows its callers to provide an index to the PM domain that it
wants to attach.

Note that, genpd_dev_pm_attach_by_id() shall only be called by the driver
core / PM core, similar to how the existing dev_pm_domain_attach() makes
use of genpd_dev_pm_attach(). However, this is implemented by following
changes on top.

Because, only one PM domain can be attached per device, genpd needs to
create a virtual device that it can attach/detach instead. More precisely,
let the new function genpd_dev_pm_attach_by_id() register a virtual struct
device via calling device_register(). Then let it attach this device to the
corresponding PM domain, rather than the one that is provided by the
caller. The actual attaching is done via re-using the existing genpd OF
functions.

At successful attachment, genpd_dev_pm_attach_by_id() returns the created
virtual device, which allows the caller to operate on it to deal with power
management. Following changes on top, provides more details in this
regards.

To deal with detaching of a PM domain for the multiple PM domains case,
let's also extend the existing genpd_dev_pm_detach() function, to cover the
cleanup of the created virtual device, via make it call device_unregister()
on it. In this way, there is no need to introduce a new function to deal
with detach for the multiple PM domain case, but instead the existing one
is re-used.

Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Acked-by: Jon Hunter <jonathanh@nvidia.com>
Tested-by: Jon Hunter <jonathanh@nvidia.com>
Reviewed-by: Viresh Kumar <viresh.kumar@linaro.org>
---
 drivers/base/power/domain.c | 80 +++++++++++++++++++++++++++++++++++++
 include/linux/pm_domain.h   |  8 ++++
 2 files changed, 88 insertions(+)

diff --git a/drivers/base/power/domain.c b/drivers/base/power/domain.c
index b1fcbf917974..4925af5c4cf0 100644
--- a/drivers/base/power/domain.c
+++ b/drivers/base/power/domain.c
@@ -2171,6 +2171,15 @@ struct generic_pm_domain *of_genpd_remove_last(struct device_node *np)
 }
 EXPORT_SYMBOL_GPL(of_genpd_remove_last);
 
+static void genpd_release_dev(struct device *dev)
+{
+	kfree(dev);
+}
+
+static struct bus_type genpd_bus_type = {
+	.name		= "genpd",
+};
+
 /**
  * genpd_dev_pm_detach - Detach a device from its PM domain.
  * @dev: Device to detach.
@@ -2208,6 +2217,10 @@ static void genpd_dev_pm_detach(struct device *dev, bool power_off)
 
 	/* Check if PM domain can be powered off after removing this device. */
 	genpd_queue_power_off_work(pd);
+
+	/* Unregister the device if it was created by genpd. */
+	if (dev->bus == &genpd_bus_type)
+		device_unregister(dev);
 }
 
 static void genpd_dev_pm_sync(struct device *dev)
@@ -2298,6 +2311,67 @@ int genpd_dev_pm_attach(struct device *dev)
 }
 EXPORT_SYMBOL_GPL(genpd_dev_pm_attach);
 
+/**
+ * genpd_dev_pm_attach_by_id - Associate a device with one of its PM domains.
+ * @dev: The device used to lookup the PM domain.
+ * @index: The index of the PM domain.
+ *
+ * Parse device's OF node to find a PM domain specifier at the provided @index.
+ * If such is found, creates a virtual device and attaches it to the retrieved
+ * pm_domain ops. To deal with detaching of the virtual device, the ->detach()
+ * callback in the struct dev_pm_domain are assigned to genpd_dev_pm_detach().
+ *
+ * Returns the created virtual device if successfully attached PM domain, NULL
+ * when the device don't need a PM domain, else an ERR_PTR() in case of
+ * failures. If a power-domain exists for the device, but cannot be found or
+ * turned on, then ERR_PTR(-EPROBE_DEFER) is returned to ensure that the device
+ * is not probed and to re-try again later.
+ */
+struct device *genpd_dev_pm_attach_by_id(struct device *dev,
+					 unsigned int index)
+{
+	struct device *genpd_dev;
+	int num_domains;
+	int ret;
+
+	if (!dev->of_node)
+		return NULL;
+
+	/* Deal only with devices using multiple PM domains. */
+	num_domains = of_count_phandle_with_args(dev->of_node, "power-domains",
+						 "#power-domain-cells");
+	if (num_domains < 2 || index >= num_domains)
+		return NULL;
+
+	/* Allocate and register device on the genpd bus. */
+	genpd_dev = kzalloc(sizeof(*genpd_dev), GFP_KERNEL);
+	if (!genpd_dev)
+		return ERR_PTR(-ENOMEM);
+
+	dev_set_name(genpd_dev, "genpd:%u:%s", index, dev_name(dev));
+	genpd_dev->bus = &genpd_bus_type;
+	genpd_dev->release = genpd_release_dev;
+
+	ret = device_register(genpd_dev);
+	if (ret) {
+		kfree(genpd_dev);
+		return ERR_PTR(ret);
+	}
+
+	/* Try to attach the device to the PM domain at the specified index. */
+	ret = __genpd_dev_pm_attach(genpd_dev, dev->of_node, index);
+	if (ret < 1) {
+		device_unregister(genpd_dev);
+		return ret ? ERR_PTR(ret) : NULL;
+	}
+
+	pm_runtime_set_active(genpd_dev);
+	pm_runtime_enable(genpd_dev);
+
+	return genpd_dev;
+}
+EXPORT_SYMBOL_GPL(genpd_dev_pm_attach_by_id);
+
 static const struct of_device_id idle_state_match[] = {
 	{ .compatible = "domain-idle-state", },
 	{ }
@@ -2457,6 +2531,12 @@ unsigned int of_genpd_opp_to_performance_state(struct device *dev,
 }
 EXPORT_SYMBOL_GPL(of_genpd_opp_to_performance_state);
 
+static int __init genpd_bus_init(void)
+{
+	return bus_register(&genpd_bus_type);
+}
+core_initcall(genpd_bus_init);
+
 #endif /* CONFIG_PM_GENERIC_DOMAINS_OF */
 
 
diff --git a/include/linux/pm_domain.h b/include/linux/pm_domain.h
index 42e0d649e653..82458e8e2e01 100644
--- a/include/linux/pm_domain.h
+++ b/include/linux/pm_domain.h
@@ -237,6 +237,8 @@ unsigned int of_genpd_opp_to_performance_state(struct device *dev,
 				struct device_node *opp_node);
 
 int genpd_dev_pm_attach(struct device *dev);
+struct device *genpd_dev_pm_attach_by_id(struct device *dev,
+					 unsigned int index);
 #else /* !CONFIG_PM_GENERIC_DOMAINS_OF */
 static inline int of_genpd_add_provider_simple(struct device_node *np,
 					struct generic_pm_domain *genpd)
@@ -282,6 +284,12 @@ static inline int genpd_dev_pm_attach(struct device *dev)
 	return 0;
 }
 
+static inline struct device *genpd_dev_pm_attach_by_id(struct device *dev,
+						       unsigned int index)
+{
+	return NULL;
+}
+
 static inline
 struct generic_pm_domain *of_genpd_remove_last(struct device_node *np)
 {
-- 
2.17.0

^ permalink raw reply related


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox