All of lore.kernel.org
 help / color / mirror / Atom feed
From: Conor Dooley <conor@kernel.org>
To: Hal Feng <hal.feng@starfivetech.com>
Cc: Conor Dooley <conor.dooley@microchip.com>,
	linux-riscv@lists.infradead.org, devicetree@vger.kernel.org,
	Palmer Dabbelt <palmer@dabbelt.com>,
	Rob Herring <robh+dt@kernel.org>,
	Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>,
	Paul Walmsley <paul.walmsley@sifive.com>,
	Albert Ou <aou@eecs.berkeley.edu>,
	Ben Dooks <ben.dooks@sifive.com>,
	Daniel Lezcano <daniel.lezcano@linaro.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	Marc Zyngier <maz@kernel.org>, Stephen Boyd <sboyd@kernel.org>,
	Michael Turquette <mturquette@baylibre.com>,
	Philipp Zabel <p.zabel@pengutronix.de>,
	Linus Walleij <linus.walleij@linaro.org>,
	Emil Renner Berthing <emil.renner.berthing@canonical.com>,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH v3 6/7] riscv: dts: starfive: Add initial StarFive JH7110 device tree
Date: Thu, 2 Feb 2023 19:41:33 +0000	[thread overview]
Message-ID: <Y9wR7Up+iObw5qoE@spud> (raw)
In-Reply-To: <df6755ed-a358-ea01-d89e-f3c004b9c297@starfivetech.com>

[-- Attachment #1: Type: text/plain, Size: 6844 bytes --]

On Fri, Feb 03, 2023 at 02:56:41AM +0800, Hal Feng wrote:
> On Wed, 1 Feb 2023 08:21:05 +0000, Conor Dooley wrote:
> > On Wed, Feb 01, 2023 at 03:21:48PM +0800, Hal Feng wrote:
> >> On Wed, 28 Dec 2022 22:48:43 +0000, Conor Dooley wrote:
> >> > On Tue, Dec 20, 2022 at 09:12:46AM +0800, Hal Feng wrote:
> > 
> >> >> +/ {
> >> >> +	compatible = "starfive,jh7110";
> >> >> +	#address-cells = <2>;
> >> >> +	#size-cells = <2>;
> >> >> +
> >> >> +	cpus {
> >> >> +		#address-cells = <1>;
> >> >> +		#size-cells = <0>;
> >> >> +
> >> >> +		S76_0: cpu@0 {
> >> >> +			compatible = "sifive,u74-mc", "riscv";
> >> > 
> >> > The label here says S76 but the compatible says u74-mc.
> >> 
> >> U74-MC has 5 cores including 1 * S7 core and 4 * U74 cores.
> >> 
> >> > Which is correct? Your docs say S7 and S76, so I would imagine that it
> >> > is actually an S76?
> >> 
> >> I found SiFive website [1] call it S76, but call it S7 in other places.
> >> So I misunderstood this. Considering the ISA difference you described
> >> as below, I think it's proper to change the label to "S7_0".
> > 
> > I'm less worried about the label & more interested in the compatible.
> > hart0 is, as you say, not a u74. Should we not be adding a "sifive,s7"
> > compatible string to Documentation/devicetree/bindings/riscv/cpus.yaml
> > and using that here instead?
> 
> First of all, it's my fault that I didn't check the revision of U74-MC
> manual, so most of my previous replies might not make sense.

No that's fine. The manual stuff confused me too when I went looking
initially, and I still get get mixed up by the fact that there are
core-complex manuals but not core manuals.

> If we add a new compatible string for S7, should we change the compatibles
> of hart1~3 to "sifive,u74" also? And then, there may be no point keeping some
> compatible strings of core complex like "sifive,u74-mc" and "sifive,u54-mc".
> I'm not sure about this.

[...]

> >> Yes, "RV64IMAC" is correct. The monitor core in U74-MC is a
> >> S7-series core, not S76.
> > 
> > Cool, thanks.
> 
> Now I think it might be another version of S76.

The SiFive docs describe the u74-mc core complex, which AFAIU you have,
as being 1x S7 & 4x U7.

I'd be happy with new binding for "sifive,s7" & then we use that here.
If you're sure it's S76, we can also use that. S76 is described, in what
docs I can see, as a core complex containing an S7, so S7 seems likely
to be correct?

u7, u74 & u74-mc are valid compatibles, added by SiFive, in commit
75e6d7248efc ("dt-bindings: riscv: Update DT binding docs to support
SiFive FU740 SoC"). Unfortunately, they never actually *used* those
compatibles for anything, and just used "sifive,bullet0" for the fu740.

I'll accept any of u7, u74 or u74-mc for those harts.

> >> >> +			tlb-split;
> >> >> +			status = "disabled";
> >> >> +
> >> >> +			cpu0_intc: interrupt-controller {
> >> >> +				compatible = "riscv,cpu-intc";
> >> >> +				interrupt-controller;
> >> >> +				#interrupt-cells = <1>;
> >> >> +			};
> >> >> +		};
> >> >> +
> >> >> +		U74_1: cpu@1 {
> >> >> +			compatible = "sifive,u74-mc", "riscv";
> >> >> +			reg = <1>;
> >> >> +			d-cache-block-size = <64>;
> >> >> +			d-cache-sets = <64>;
> >> >> +			d-cache-size = <32768>;
> >> >> +			d-tlb-sets = <1>;
> >> >> +			d-tlb-size = <40>;
> >> >> +			device_type = "cpu";
> >> >> +			i-cache-block-size = <64>;
> >> >> +			i-cache-sets = <64>;
> >> >> +			i-cache-size = <32768>;
> >> >> +			i-tlb-sets = <1>;
> >> >> +			i-tlb-size = <40>;
> >> >> +			mmu-type = "riscv,sv39";
> >> >> +			next-level-cache = <&ccache>;
> >> >> +			riscv,isa = "rv64imafdc";
> >> > 
> >> > That also begs the question:
> >> > Do your u74s support RV64GBC, as the (current) SiFive documentation
> >> > suggests?
> >> 
> >> Actually, U74 doesn't support the full B extension, and the SiFive doc [1]
> > 
> > Yeah, I knew asking that question that the "RV64GBC" in SiFive's online
> > documentation was using outdated terminology. Also, that is not the doc
> > for your core complex as far as I can tell. That is the document for
> > impid 0x0621_1222, whereas (IIRC) your core is 0x0421_0427.
> > Jess and I had a look one evening but could not find the 21G1.02.00
> > revision of this document, which is the one corresponding to 0x421_0427.
> > See Table 92 for more details.
> 
> I found the 21G1.02.00 revision on StarFive internal net, but I'm not sure
> whether I can make it public and I am checking this.

Yeah, certainly don't do anything without cross-checking!

> This revision records
> that the ISA of 21G1.02.00 U74 is "RV64GCB" and ISA of 21G1.02.00 S7 is
> "RV64IMACB". I am asking someone to check with SiFive whether both 21G1.02.00
> U74 and S7 support the full B extension.

Having cross-checked a 21G1.01.00 document against a 21G2.01.00 one, I'm
99% sure that you have _Zba_Zbb.
The G2.01 document says _Zba_Zbb & has the same instructions listed as
supported as the G1.02 one.
I've also tried the Zbb support patches posted by Heiko [2] on a
VisionFive V2 and had them work - which is why a definitive statement on
the version of Zbb supported would be really great to have!

[2] - https://lore.kernel.org/linux-riscv/20230113212301.3534711-1-heiko@sntech.de/

> >> describes the ISA of U74 is "RV64GC_Zba_Zbb_Sscofpmf" which "G" includes
> >> "IMAFD".
> > 
> > I could not find the 21G1.02.00 version of this document online, but I
> > was able to find the 21G1.01.00 version of it & that version does not
> > support the Sscofpmf extension (but does have Zba/Zbb support).
> > 
> >> "_Zba_Zbb_Sscofpmf" is not shown in other device trees such as
> >> jh7100.dtsi and fu740-c000.dtsi, so I didn't show them here.
> > 
> > Just because other devicetrees omit them, doesn't mean that you should
> > too!
> > This compatible should be an accurate description of your hardware, so
> > you should add what you actually have.
> 
> Will keep it in mind. Thank you.

FWIW, the deadline for getting material in for v6.3 has already passed,
so you can send the next version of this series without waiting for
clarification on the compatibles & ISA string. We should have plenty of
time to get those fixed up before the series gets applied.

Thanks,
Conor.

> > If you have Zba and Zbb, then add them.
> > I would double check against your internal documentation for 21G2.02.00
> > as to whether you do have Sscofpmf, and if you do, add that too!
> > 
> > That way, whenever support for those extensions lands, the jh7110 will
> > automatically pick it up, rather than needing to have them retrofitted.
> > 
> >> [1] https://sifive.cdn.prismic.io/sifive/2dd11994-693c-4360-8aea-5453d8642c42_u74mc_core_complex_manual_21G3.pdf

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

WARNING: multiple messages have this Message-ID (diff)
From: Conor Dooley <conor@kernel.org>
To: Hal Feng <hal.feng@starfivetech.com>
Cc: Conor Dooley <conor.dooley@microchip.com>,
	linux-riscv@lists.infradead.org, devicetree@vger.kernel.org,
	Palmer Dabbelt <palmer@dabbelt.com>,
	Rob Herring <robh+dt@kernel.org>,
	Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>,
	Paul Walmsley <paul.walmsley@sifive.com>,
	Albert Ou <aou@eecs.berkeley.edu>,
	Ben Dooks <ben.dooks@sifive.com>,
	Daniel Lezcano <daniel.lezcano@linaro.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	Marc Zyngier <maz@kernel.org>, Stephen Boyd <sboyd@kernel.org>,
	Michael Turquette <mturquette@baylibre.com>,
	Philipp Zabel <p.zabel@pengutronix.de>,
	Linus Walleij <linus.walleij@linaro.org>,
	Emil Renner Berthing <emil.renner.berthing@canonical.com>,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH v3 6/7] riscv: dts: starfive: Add initial StarFive JH7110 device tree
Date: Thu, 2 Feb 2023 19:41:33 +0000	[thread overview]
Message-ID: <Y9wR7Up+iObw5qoE@spud> (raw)
In-Reply-To: <df6755ed-a358-ea01-d89e-f3c004b9c297@starfivetech.com>


[-- Attachment #1.1: Type: text/plain, Size: 6844 bytes --]

On Fri, Feb 03, 2023 at 02:56:41AM +0800, Hal Feng wrote:
> On Wed, 1 Feb 2023 08:21:05 +0000, Conor Dooley wrote:
> > On Wed, Feb 01, 2023 at 03:21:48PM +0800, Hal Feng wrote:
> >> On Wed, 28 Dec 2022 22:48:43 +0000, Conor Dooley wrote:
> >> > On Tue, Dec 20, 2022 at 09:12:46AM +0800, Hal Feng wrote:
> > 
> >> >> +/ {
> >> >> +	compatible = "starfive,jh7110";
> >> >> +	#address-cells = <2>;
> >> >> +	#size-cells = <2>;
> >> >> +
> >> >> +	cpus {
> >> >> +		#address-cells = <1>;
> >> >> +		#size-cells = <0>;
> >> >> +
> >> >> +		S76_0: cpu@0 {
> >> >> +			compatible = "sifive,u74-mc", "riscv";
> >> > 
> >> > The label here says S76 but the compatible says u74-mc.
> >> 
> >> U74-MC has 5 cores including 1 * S7 core and 4 * U74 cores.
> >> 
> >> > Which is correct? Your docs say S7 and S76, so I would imagine that it
> >> > is actually an S76?
> >> 
> >> I found SiFive website [1] call it S76, but call it S7 in other places.
> >> So I misunderstood this. Considering the ISA difference you described
> >> as below, I think it's proper to change the label to "S7_0".
> > 
> > I'm less worried about the label & more interested in the compatible.
> > hart0 is, as you say, not a u74. Should we not be adding a "sifive,s7"
> > compatible string to Documentation/devicetree/bindings/riscv/cpus.yaml
> > and using that here instead?
> 
> First of all, it's my fault that I didn't check the revision of U74-MC
> manual, so most of my previous replies might not make sense.

No that's fine. The manual stuff confused me too when I went looking
initially, and I still get get mixed up by the fact that there are
core-complex manuals but not core manuals.

> If we add a new compatible string for S7, should we change the compatibles
> of hart1~3 to "sifive,u74" also? And then, there may be no point keeping some
> compatible strings of core complex like "sifive,u74-mc" and "sifive,u54-mc".
> I'm not sure about this.

[...]

> >> Yes, "RV64IMAC" is correct. The monitor core in U74-MC is a
> >> S7-series core, not S76.
> > 
> > Cool, thanks.
> 
> Now I think it might be another version of S76.

The SiFive docs describe the u74-mc core complex, which AFAIU you have,
as being 1x S7 & 4x U7.

I'd be happy with new binding for "sifive,s7" & then we use that here.
If you're sure it's S76, we can also use that. S76 is described, in what
docs I can see, as a core complex containing an S7, so S7 seems likely
to be correct?

u7, u74 & u74-mc are valid compatibles, added by SiFive, in commit
75e6d7248efc ("dt-bindings: riscv: Update DT binding docs to support
SiFive FU740 SoC"). Unfortunately, they never actually *used* those
compatibles for anything, and just used "sifive,bullet0" for the fu740.

I'll accept any of u7, u74 or u74-mc for those harts.

> >> >> +			tlb-split;
> >> >> +			status = "disabled";
> >> >> +
> >> >> +			cpu0_intc: interrupt-controller {
> >> >> +				compatible = "riscv,cpu-intc";
> >> >> +				interrupt-controller;
> >> >> +				#interrupt-cells = <1>;
> >> >> +			};
> >> >> +		};
> >> >> +
> >> >> +		U74_1: cpu@1 {
> >> >> +			compatible = "sifive,u74-mc", "riscv";
> >> >> +			reg = <1>;
> >> >> +			d-cache-block-size = <64>;
> >> >> +			d-cache-sets = <64>;
> >> >> +			d-cache-size = <32768>;
> >> >> +			d-tlb-sets = <1>;
> >> >> +			d-tlb-size = <40>;
> >> >> +			device_type = "cpu";
> >> >> +			i-cache-block-size = <64>;
> >> >> +			i-cache-sets = <64>;
> >> >> +			i-cache-size = <32768>;
> >> >> +			i-tlb-sets = <1>;
> >> >> +			i-tlb-size = <40>;
> >> >> +			mmu-type = "riscv,sv39";
> >> >> +			next-level-cache = <&ccache>;
> >> >> +			riscv,isa = "rv64imafdc";
> >> > 
> >> > That also begs the question:
> >> > Do your u74s support RV64GBC, as the (current) SiFive documentation
> >> > suggests?
> >> 
> >> Actually, U74 doesn't support the full B extension, and the SiFive doc [1]
> > 
> > Yeah, I knew asking that question that the "RV64GBC" in SiFive's online
> > documentation was using outdated terminology. Also, that is not the doc
> > for your core complex as far as I can tell. That is the document for
> > impid 0x0621_1222, whereas (IIRC) your core is 0x0421_0427.
> > Jess and I had a look one evening but could not find the 21G1.02.00
> > revision of this document, which is the one corresponding to 0x421_0427.
> > See Table 92 for more details.
> 
> I found the 21G1.02.00 revision on StarFive internal net, but I'm not sure
> whether I can make it public and I am checking this.

Yeah, certainly don't do anything without cross-checking!

> This revision records
> that the ISA of 21G1.02.00 U74 is "RV64GCB" and ISA of 21G1.02.00 S7 is
> "RV64IMACB". I am asking someone to check with SiFive whether both 21G1.02.00
> U74 and S7 support the full B extension.

Having cross-checked a 21G1.01.00 document against a 21G2.01.00 one, I'm
99% sure that you have _Zba_Zbb.
The G2.01 document says _Zba_Zbb & has the same instructions listed as
supported as the G1.02 one.
I've also tried the Zbb support patches posted by Heiko [2] on a
VisionFive V2 and had them work - which is why a definitive statement on
the version of Zbb supported would be really great to have!

[2] - https://lore.kernel.org/linux-riscv/20230113212301.3534711-1-heiko@sntech.de/

> >> describes the ISA of U74 is "RV64GC_Zba_Zbb_Sscofpmf" which "G" includes
> >> "IMAFD".
> > 
> > I could not find the 21G1.02.00 version of this document online, but I
> > was able to find the 21G1.01.00 version of it & that version does not
> > support the Sscofpmf extension (but does have Zba/Zbb support).
> > 
> >> "_Zba_Zbb_Sscofpmf" is not shown in other device trees such as
> >> jh7100.dtsi and fu740-c000.dtsi, so I didn't show them here.
> > 
> > Just because other devicetrees omit them, doesn't mean that you should
> > too!
> > This compatible should be an accurate description of your hardware, so
> > you should add what you actually have.
> 
> Will keep it in mind. Thank you.

FWIW, the deadline for getting material in for v6.3 has already passed,
so you can send the next version of this series without waiting for
clarification on the compatibles & ISA string. We should have plenty of
time to get those fixed up before the series gets applied.

Thanks,
Conor.

> > If you have Zba and Zbb, then add them.
> > I would double check against your internal documentation for 21G2.02.00
> > as to whether you do have Sscofpmf, and if you do, add that too!
> > 
> > That way, whenever support for those extensions lands, the jh7110 will
> > automatically pick it up, rather than needing to have them retrofitted.
> > 
> >> [1] https://sifive.cdn.prismic.io/sifive/2dd11994-693c-4360-8aea-5453d8642c42_u74mc_core_complex_manual_21G3.pdf

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

[-- Attachment #2: Type: text/plain, Size: 161 bytes --]

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

  reply	other threads:[~2023-02-02 19:41 UTC|newest]

Thread overview: 112+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-12-20  1:12 [PATCH v3 0/7] Basic device tree support for StarFive JH7110 RISC-V SoC Hal Feng
2022-12-20  1:12 ` Hal Feng
2022-12-20  1:12 ` [PATCH v3 1/7] dt-bindings: riscv: Add StarFive JH7110 SoC and VisionFive 2 board Hal Feng
2022-12-20  1:12   ` Hal Feng
2022-12-20 10:05   ` Krzysztof Kozlowski
2022-12-20 10:05     ` Krzysztof Kozlowski
2022-12-23  2:05     ` Hal Feng
2022-12-23  2:05       ` Hal Feng
2022-12-20 20:58   ` Conor Dooley
2022-12-20 20:58     ` Conor Dooley
2022-12-23  2:15     ` Hal Feng
2022-12-23  2:15       ` Hal Feng
2022-12-20  1:12 ` [PATCH v3 2/7] dt-bindings: timer: Add StarFive JH7110 clint Hal Feng
2022-12-20  1:12   ` Hal Feng
2022-12-20  1:12 ` [PATCH v3 3/7] dt-bindings: interrupt-controller: Add StarFive JH7110 plic Hal Feng
2022-12-20  1:12   ` Hal Feng
2022-12-20  1:12 ` [PATCH v3 4/7] dt-bindings: sifive,ccache0: Support StarFive JH7110 SoC Hal Feng
2022-12-20  1:12   ` Hal Feng
2022-12-20 20:21   ` Rob Herring
2022-12-20 20:21     ` Rob Herring
2022-12-20  1:12 ` [PATCH v3 5/7] soc: sifive: ccache: Add StarFive JH7110 support Hal Feng
2022-12-20  1:12   ` Hal Feng
2022-12-20 21:14   ` Conor Dooley
2022-12-20 21:14     ` Conor Dooley
2022-12-20  1:12 ` [PATCH v3 6/7] riscv: dts: starfive: Add initial StarFive JH7110 device tree Hal Feng
2022-12-20  1:12   ` Hal Feng
2022-12-20 10:10   ` Krzysztof Kozlowski
2022-12-20 10:10     ` Krzysztof Kozlowski
2022-12-25 10:31     ` Hal Feng
2022-12-25 10:31       ` Hal Feng
2022-12-25 11:56       ` Krzysztof Kozlowski
2022-12-25 11:56         ` Krzysztof Kozlowski
2022-12-20 21:31   ` Conor Dooley
2022-12-20 21:31     ` Conor Dooley
2022-12-25 14:31     ` Hal Feng
2022-12-25 14:31       ` Hal Feng
2022-12-27 20:58       ` Conor Dooley
2022-12-27 20:58         ` Conor Dooley
2022-12-28 22:48   ` Conor Dooley
2022-12-28 22:48     ` Conor Dooley
2022-12-29  5:25     ` Icenowy Zheng
2022-12-29  5:25       ` Icenowy Zheng
2022-12-29  9:02       ` Conor Dooley
2022-12-29  9:02         ` Conor Dooley
2023-02-01  7:53         ` Hal Feng
2023-02-01  7:53           ` Hal Feng
2023-02-01  7:31       ` Hal Feng
2023-02-01  7:31         ` Hal Feng
2023-02-01  7:21     ` Hal Feng
2023-02-01  7:21       ` Hal Feng
2023-02-01  8:21       ` Conor Dooley
2023-02-01  8:21         ` Conor Dooley
2023-02-02 18:56         ` Hal Feng
2023-02-02 18:56           ` Hal Feng
2023-02-02 19:41           ` Conor Dooley [this message]
2023-02-02 19:41             ` Conor Dooley
2023-02-09 11:11             ` Conor Dooley
2023-02-09 11:11               ` Conor Dooley
2023-02-13  9:41               ` Hal Feng
2023-02-13  9:41                 ` Hal Feng
2023-02-13 10:07                 ` Conor Dooley
2023-02-13 10:07                   ` Conor Dooley
2023-02-14  2:37                   ` Hal Feng
2023-02-14  2:37                     ` Hal Feng
2023-02-15  3:07             ` Hal Feng
2023-02-15  3:07               ` Hal Feng
2023-02-15  7:42               ` Conor Dooley
2023-02-15  7:42                 ` Conor Dooley
2023-02-15  7:59                 ` Conor Dooley
2023-02-15  7:59                   ` Conor Dooley
2023-01-31  2:00   ` Hal Feng
2023-01-31  2:00     ` Hal Feng
2023-01-31  6:17     ` Conor Dooley
2023-01-31  6:17       ` Conor Dooley
2023-02-02  2:42       ` Hal Feng
2023-02-02  2:42         ` Hal Feng
2023-02-02  6:19         ` Conor Dooley
2023-02-02  6:19           ` Conor Dooley
2022-12-20  1:12 ` [PATCH v3 7/7] riscv: dts: starfive: Add StarFive JH7110 VisionFive 2 board " Hal Feng
2022-12-20  1:12   ` Hal Feng
2022-12-20 21:26   ` Conor Dooley
2022-12-20 21:26     ` Conor Dooley
2022-12-23  3:12     ` Hal Feng
2022-12-23  3:12       ` Hal Feng
2022-12-28 22:49       ` Conor Dooley
2022-12-28 22:49         ` Conor Dooley
2023-01-10 17:59   ` Conor Dooley
2023-01-10 17:59     ` Conor Dooley
2023-01-18 23:43     ` Conor Dooley
2023-01-18 23:43       ` Conor Dooley
2023-02-14  9:53   ` Emil Renner Berthing
2023-02-14  9:53     ` Emil Renner Berthing
2023-02-15 14:03     ` Hal Feng
2023-02-15 14:03       ` Hal Feng
2023-02-16  9:27       ` Emil Renner Berthing
2023-02-16  9:27         ` Emil Renner Berthing
2023-02-16  9:50         ` Conor Dooley
2023-02-16  9:50           ` Conor Dooley
2023-02-16 10:09           ` Conor Dooley
2023-02-16 10:09             ` Conor Dooley
2023-02-16 10:32             ` Emil Renner Berthing
2023-02-16 10:32               ` Emil Renner Berthing
2023-02-16 12:27               ` Hal Feng
2023-02-16 12:27                 ` Hal Feng
2023-02-16 13:02                 ` Conor Dooley
2023-02-16 13:02                   ` Conor Dooley
2022-12-26 23:01 ` [PATCH v3 0/7] Basic device tree support for StarFive JH7110 RISC-V SoC Conor Dooley
2022-12-26 23:01   ` Conor Dooley
2022-12-27  7:58   ` Krzysztof Kozlowski
2022-12-27  7:58     ` Krzysztof Kozlowski
2022-12-27 14:20     ` Conor Dooley
2022-12-27 14:20       ` Conor Dooley

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Y9wR7Up+iObw5qoE@spud \
    --to=conor@kernel.org \
    --cc=aou@eecs.berkeley.edu \
    --cc=ben.dooks@sifive.com \
    --cc=conor.dooley@microchip.com \
    --cc=daniel.lezcano@linaro.org \
    --cc=devicetree@vger.kernel.org \
    --cc=emil.renner.berthing@canonical.com \
    --cc=hal.feng@starfivetech.com \
    --cc=krzysztof.kozlowski+dt@linaro.org \
    --cc=linus.walleij@linaro.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-riscv@lists.infradead.org \
    --cc=maz@kernel.org \
    --cc=mturquette@baylibre.com \
    --cc=p.zabel@pengutronix.de \
    --cc=palmer@dabbelt.com \
    --cc=paul.walmsley@sifive.com \
    --cc=robh+dt@kernel.org \
    --cc=sboyd@kernel.org \
    --cc=tglx@linutronix.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.