All of lore.kernel.org
 help / color / mirror / Atom feed
From: <Conor.Dooley@microchip.com>
To: <geert@linux-m68k.org>
Cc: <linus.walleij@linaro.org>, <bgolaszewski@baylibre.com>,
	<robh+dt@kernel.org>, <jassisinghbrar@gmail.com>,
	<paul.walmsley@sifive.com>, <palmer@dabbelt.com>,
	<aou@eecs.berkeley.edu>, <a.zummo@towertech.it>,
	<alexandre.belloni@bootlin.com>, <broonie@kernel.org>,
	<gregkh@linuxfoundation.org>, <Lewis.Hanly@microchip.com>,
	<Daire.McNamara@microchip.com>, <atish.patra@wdc.com>,
	<Ivan.Griffin@microchip.com>, <linux-gpio@vger.kernel.org>,
	<devicetree@vger.kernel.org>, <linux-kernel@vger.kernel.org>,
	<linux-i2c@vger.kernel.org>, <linux-riscv@lists.infradead.org>,
	<linux-crypto@vger.kernel.org>, <linux-rtc@vger.kernel.org>,
	<linux-spi@vger.kernel.org>, <linux-usb@vger.kernel.org>,
	<krzysztof.kozlowski@canonical.com>, <bin.meng@windriver.com>
Subject: Re: [PATCH 12/13] riscv: icicle-kit: update microchip icicle kit device tree
Date: Wed, 10 Nov 2021 14:19:51 +0000	[thread overview]
Message-ID: <0e379411-2469-8c78-1a3f-0645579a967c@microchip.com> (raw)
In-Reply-To: <CAMuHMdWEhJj0Cqt3sgGvgZe7JSFqBmTgtZRkom30NKqEW27NvQ@mail.gmail.com>

On 09/11/2021 09:04, Geert Uytterhoeven wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
> 
> Hi Conor,
> 
> On Mon, Nov 8, 2021 at 4:07 PM <conor.dooley@microchip.com> wrote:
>> From: Conor Dooley <conor.dooley@microchip.com>
>>
>> Update the device tree for the icicle kit by splitting it into a third part,
>> which contains peripherals in the fpga fabric, add new peripherals
>> (spi, qspi, gpio, rtc, pcie, system services, i2c), update parts of the memory
>> map which have been changed.
>>
>> Signed-off-by: Conor Dooley <conor.dooley@microchip.com>
> 
> Thanks for your patch!
> 
> Please split it into logical separated parts.
yeah, ive split it into several patches - one for the splitting into 3, 
one for the new defines, one for the changes to existing nodes and one 
for node additions.

> 
>> --- /dev/null
>> +++ b/arch/riscv/boot/dts/microchip/microchip-mpfs-fabric.dtsi
>> @@ -0,0 +1,21 @@
>> +// SPDX-License-Identifier: (GPL-2.0 OR MIT)
>> +/* Copyright (c) 2020-2021 Microchip Technology Inc */
>> +
>> +/ {
>> +       fpgadma: fpgadma@60020000 {
>> +               compatible = "microchip,mpfs-fpga-dma-uio";
>> +               #address-cells = <1>;
>> +               #size-cells = <0>;
>> +               reg = <0x0 0x60020000 0x0 0x1000>;
>> +               interrupt-parent = <&plic>;
>> +               interrupts = <PLIC_INT_FABRIC_F2H_2>;
>> +               status = "okay";
>> +       };
>> +
>> +       fpgalsram: fpga_lsram@61000000 {
>> +               compatible = "generic-uio";
>> +               reg = <0x0 0x61000000 0x0 0x0001000
>> +                       0x14 0x00000000 0x0 0x00010000>;
> 
> Please group by angular brackets, to increase readability, and support
> automatic validation:
> 
> <0x0 0x61000000 0x0 0x0001000>, <0x14 0x00000000 0x0 0x00010000>
> 
>> +               status = "okay";
>> +       };
> 
> Do we really want UIO nodes in upstream DT?
As I said in the replies to another patch this is my first time doing 
any upstreaming of a device tree, i didnt realise that this would be a 
problem.
> 
>> +};
>> diff --git a/arch/riscv/boot/dts/microchip/microchip-mpfs-icicle-kit.dts b/arch/riscv/boot/dts/microchip/microchip-mpfs-icicle-kit.dts
>> index fc1e5869df1b..4212129fcdf1 100644
>> --- a/arch/riscv/boot/dts/microchip/microchip-mpfs-icicle-kit.dts
>> +++ b/arch/riscv/boot/dts/microchip/microchip-mpfs-icicle-kit.dts
>> @@ -1,5 +1,5 @@
>>   // SPDX-License-Identifier: (GPL-2.0 OR MIT)
>> -/* Copyright (c) 2020 Microchip Technology Inc */
>> +/* Copyright (c) 2020-2021 Microchip Technology Inc */
>>
>>   /dts-v1/;
>>
>> @@ -13,72 +13,187 @@ / {
>>          compatible = "microchip,mpfs-icicle-kit", "microchip,mpfs";
>>
>>          aliases {
>> -               ethernet0 = &emac1;
>> -               serial0 = &serial0;
>> -               serial1 = &serial1;
>> -               serial2 = &serial2;
>> -               serial3 = &serial3;
>> +               mmuart0 = &mmuart0;
>> +               mmuart1 = &mmuart1;
>> +               mmuart2 = &mmuart2;
>> +               mmuart3 = &mmuart3;
>> +               mmuart4 = &mmuart4;
> 
> Why? SerialN is the standard alias name.
we changed the label to mmuart to match the microchip documentation. 
would it make more sense to call mmuart but alias it to serial?
ie serial0 = &mmuart0;
> 
>>          };
> 
>>
>> -&emac0 {
>> +&spi0 {
>> +       status = "okay";
>> +       spidev@0 {
>> +               compatible = "spidev";
> 
> Please don't use "spidev", but a proper compatible value describing
> what is really connected.  If you want to use it with spidev (which
> is software policy, not hardware description), add that compatible
> value to drivers/spi/spidev.c:spidev_dt_ids[], or use driver_override
> in sysfs at runtime.
as i said to Krzysztof - this one was an oversight from me, that 
compatible has never been "spidev"  on its own in our internal tree and 
i mustve accidentally omitted the vendor string while making these patches.

Either way, after talking some more we decided that this entry is not 
appropriate anyway and i will drop it.
> 
>> +               reg = <0>; /* CS 0 */
>> +               spi-max-frequency = <10000000>;
>> +               status = "okay";
>> +       };
>> +};
>> +
>> +&spi1 {
>> +       status = "okay";
> 
> No slave devices specified?
no, but its exposed
> 
>> +};
>> +
>> +&qspi {
>> +       status = "okay";
>> +};
>> +
>> +&i2c0 {
>> +       status = "okay";
>> +};
>> +
>> +&i2c1 {
>> +       status = "okay";
>> +       pac193x: pac193x@10 {
> 
> adc@, I guess?
sure
> 
>> +               compatible = "microchip,pac1934";
>> +               reg = <0x10>;
>> +               samp-rate = <64>;
>> +               status = "okay";
>> +               ch0: channel0 {
>> +                       uohms-shunt-res = <10000>;
>> +                       rail-name = "VDDREG";
>> +                       channel_enabled;
>> +               };
>> +               ch1: channel1 {
>> +                       uohms-shunt-res = <10000>;
>> +                       rail-name = "VDDA25";
>> +                       channel_enabled;
>> +               };
>> +               ch2: channel2 {
>> +                       uohms-shunt-res = <10000>;
>> +                       rail-name = "VDD25";
>> +                       channel_enabled;
>> +               };
>> +               ch3: channel3 {
>> +                       uohms-shunt-res = <10000>;
>> +                       rail-name = "VDDA_REG";
>> +                       channel_enabled;
>> +               };
>> +       };
>> +};
> 
>> +&gpio2 {
>> +       interrupts = <PLIC_INT_GPIO2_NON_DIRECT
>> +               PLIC_INT_GPIO2_NON_DIRECT
>> +               PLIC_INT_GPIO2_NON_DIRECT
>> +               PLIC_INT_GPIO2_NON_DIRECT
>> +               PLIC_INT_GPIO2_NON_DIRECT
>> +               PLIC_INT_GPIO2_NON_DIRECT
>> +               PLIC_INT_GPIO2_NON_DIRECT
>> +               PLIC_INT_GPIO2_NON_DIRECT
>> +               PLIC_INT_GPIO2_NON_DIRECT
>> +               PLIC_INT_GPIO2_NON_DIRECT
>> +               PLIC_INT_GPIO2_NON_DIRECT
>> +               PLIC_INT_GPIO2_NON_DIRECT
>> +               PLIC_INT_GPIO2_NON_DIRECT
>> +               PLIC_INT_GPIO2_NON_DIRECT
>> +               PLIC_INT_GPIO2_NON_DIRECT
>> +               PLIC_INT_GPIO2_NON_DIRECT
>> +               PLIC_INT_GPIO2_NON_DIRECT
>> +               PLIC_INT_GPIO2_NON_DIRECT
>> +               PLIC_INT_GPIO2_NON_DIRECT
>> +               PLIC_INT_GPIO2_NON_DIRECT
>> +               PLIC_INT_GPIO2_NON_DIRECT
>> +               PLIC_INT_GPIO2_NON_DIRECT
>> +               PLIC_INT_GPIO2_NON_DIRECT
>> +               PLIC_INT_GPIO2_NON_DIRECT
>> +               PLIC_INT_GPIO2_NON_DIRECT
>> +               PLIC_INT_GPIO2_NON_DIRECT
>> +               PLIC_INT_GPIO2_NON_DIRECT
>> +               PLIC_INT_GPIO2_NON_DIRECT
>> +               PLIC_INT_GPIO2_NON_DIRECT
>> +               PLIC_INT_GPIO2_NON_DIRECT
>> +               PLIC_INT_GPIO2_NON_DIRECT
>> +               PLIC_INT_GPIO2_NON_DIRECT>;
> 
> Why override interrupts in the board .dts file?
> Doesn't this belong in the SoC .dtsi file?
The interrupt setup for the gpio isnt fixed, there is an option to 
either connect the individual gpio interrupts to the plic *or* they can 
be connected to a per gpio controller common interrupt, and it is up to 
the driver to read a register to determine which interrupt triggered the 
common/NON_DIRECT interrupt. This decision is made by a write to a 
system register in application code, which to us didn't seem like it 
belonged in the soc .dtsi.

Using the common interrupt for GPIO2 is the default on the 
polarfire-soc, there are only 38 per gpio line interrupts available of 
which 14 are connected to gpio0 and 24 to gpio1.

> Please group using angular brackets.
> 
>> --- a/arch/riscv/boot/dts/microchip/microchip-mpfs.dtsi
>> +++ b/arch/riscv/boot/dts/microchip/microchip-mpfs.dtsi
> 
>> @@ -145,49 +149,55 @@ cpu4_intc: interrupt-controller {
>>          soc {
>>                  #address-cells = <2>;
>>                  #size-cells = <2>;
>> -               compatible = "simple-bus";
>> +               compatible = "microchip,mpfs-soc", "simple-bus";
>>                  ranges;
>>
>> -               cache-controller@2010000 {
>> +               cctrllr: cache-controller@2010000 {
>>                          compatible = "sifive,fu540-c000-ccache", "cache";
>> +                       reg = <0x0 0x2010000 0x0 0x1000>;
>> +                       interrupt-parent = <&plic>;
>> +                       interrupts = <PLIC_INT_L2_METADATA_CORR
>> +                               PLIC_INT_L2_METADAT_UNCORR
>> +                               PLIC_INT_L2_DATA_CORR>;
> 
> Please group using angular brackets.
> 
>>                          cache-block-size = <64>;
>>                          cache-level = <2>;
>>                          cache-sets = <1024>;
>>                          cache-size = <2097152>;
>>                          cache-unified;
>> -                       interrupt-parent = <&plic>;
>> -                       interrupts = <1 2 3>;
>> -                       reg = <0x0 0x2010000 0x0 0x1000>;
>>                  };
>>
>> -               clint@2000000 {
>> +               clint: clint@2000000 {
>>                          compatible = "sifive,fu540-c000-clint", "sifive,clint0";
>>                          reg = <0x0 0x2000000 0x0 0xC000>;
>> -                       interrupts-extended = <&cpu0_intc 3 &cpu0_intc 7
>> -                                               &cpu1_intc 3 &cpu1_intc 7
>> -                                               &cpu2_intc 3 &cpu2_intc 7
>> -                                               &cpu3_intc 3 &cpu3_intc 7
>> -                                               &cpu4_intc 3 &cpu4_intc 7>;
>> +                       interrupts-extended =
>> +                                       <&cpu0_intc HART_INT_M_SOFT &cpu0_intc HART_INT_M_TIMER
>> +                                        &cpu1_intc HART_INT_M_SOFT &cpu1_intc HART_INT_M_TIMER
>> +                                        &cpu2_intc HART_INT_M_SOFT &cpu2_intc HART_INT_M_TIMER
>> +                                        &cpu3_intc HART_INT_M_SOFT &cpu3_intc HART_INT_M_TIMER
>> +                                        &cpu4_intc HART_INT_M_SOFT &cpu4_intc HART_INT_M_TIMER>;
> 
> Please group using angular brackets.
> 
>>                  };
>>
>>                  plic: interrupt-controller@c000000 {
>> -                       #interrupt-cells = <1>;
>> -                       compatible = "sifive,fu540-c000-plic", "sifive,plic-1.0.0";
>> +                       compatible = "sifive,plic-1.0.0";
> 
> Why drop the first one again?
we felt it didnt make sense to have something that specifically 
references the fu540 in the device tree for this board.
> 
>>                          reg = <0x0 0xc000000 0x0 0x4000000>;
>> +                       #interrupt-cells = <1>;
>>                          riscv,ndev = <186>;
>>                          interrupt-controller;
>> -                       interrupts-extended = <&cpu0_intc 11
>> -                                       &cpu1_intc 11 &cpu1_intc 9
>> -                                       &cpu2_intc 11 &cpu2_intc 9
>> -                                       &cpu3_intc 11 &cpu3_intc 9
>> -                                       &cpu4_intc 11 &cpu4_intc 9>;
>> +                       interrupts-extended = <&cpu0_intc HART_INT_M_EXT
>> +                                       &cpu1_intc HART_INT_M_EXT &cpu1_intc HART_INT_S_EXT
>> +                                       &cpu2_intc HART_INT_M_EXT &cpu2_intc HART_INT_S_EXT
>> +                                       &cpu3_intc HART_INT_M_EXT &cpu3_intc HART_INT_S_EXT
>> +                                       &cpu4_intc HART_INT_M_EXT &cpu4_intc HART_INT_S_EXT>;
>>                  };
>>
>> -               dma@3000000 {
>> -                       compatible = "sifive,fu540-c000-pdma";
>> +               pdma: pdma@3000000 {
>> +                       compatible = "microchip,mpfs-pdma-uio";
>>                          reg = <0x0 0x3000000 0x0 0x8000>;
>>                          interrupt-parent = <&plic>;
>> -                       interrupts = <23 24 25 26 27 28 29 30>;
>> +                       interrupts = <PLIC_INT_DMA_CH0_DONE PLIC_INT_DMA_CH0_ERR
>> +                               PLIC_INT_DMA_CH1_DONE PLIC_INT_DMA_CH1_ERR
>> +                               PLIC_INT_DMA_CH2_DONE PLIC_INT_DMA_CH2_ERR
>> +                               PLIC_INT_DMA_CH3_DONE PLIC_INT_DMA_CH3_ERR>;
> 
> Please group using angular brackets.
> 
>>                          #dma-cells = <1>;
>>                  };
>>
>> @@ -205,7 +215,7 @@ clkcfg: clkcfg@20002000 {
>>                          clocks = <&refclk>;
>>                          #clock-cells = <1>;
>>                          clock-output-names = "cpu", "axi", "ahb", "envm",       /* 0-3   */
>> -                                "mac0", "mac1", "mmc", "timer",                /* 4-7   */
>> +                               "mac0", "mac1", "mmc", "timer",                 /* 4-7   */
>>                                  "mmuart0", "mmuart1", "mmuart2", "mmuart3",     /* 8-11  */
>>                                  "mmuart4", "spi0", "spi1", "i2c0",              /* 12-15 */
>>                                  "i2c1", "can0", "can1", "usb",                  /* 16-19 */
> 
> No need for clock-output-names at all.
> 
>>
>> -               emac1: ethernet@20112000 {
>> +               mac0: ethernet@20110000 {
>>                          compatible = "cdns,macb";
>> -                       reg = <0x0 0x20112000 0x0 0x2000>;
>> +                       #address-cells = <1>;
>> +                       #size-cells = <0>;
>> +                       reg = <0x0 0x20110000 0x0 0x2000>;
>> +                       clocks = <&clkcfg CLK_MAC0>, <&clkcfg CLK_AHB>;
>> +                       clock-names = "pclk", "hclk";
>>                          interrupt-parent = <&plic>;
>> -                       interrupts = <70 71 72 73>;
>> -                       local-mac-address = [00 00 00 00 00 00];
>> -                       clocks = <&clkcfg 5>, <&clkcfg 2>;
>> +                       interrupts = <PLIC_INT_MAC0_INT
>> +                               PLIC_INT_MAC0_QUEUE1
>> +                               PLIC_INT_MAC0_QUEUE2
>> +                               PLIC_INT_MAC0_QUEUE3
>> +                               PLIC_INT_MAC0_EMAC
>> +                               PLIC_INT_MAC0_MMSL>;
> 
> Please group using angular brackets.
> 
>> +                       mac-address = [56 34 12 00 FC 01];
> 
> Please drop this.
Is the problem here having mac-address instead of local-, having either 
at all or that we have populated it rather than just filling with 0s?
We set it in u-boot anyway, so I think dropping entirely is okay.
> 
>>                          status = "disabled";
>> +               };
>>
>> +               rtc: rtc@20124000 {
>> +                       compatible = "microchip,mpfs-rtc";
>>                          #address-cells = <1>;
>>                          #size-cells = <0>;
>> +                       reg = <0x0 0x20124000 0x0 0x1000>;
>> +                       clocks = <&clkcfg CLK_RTC>;
>> +                       clock-names = "rtc";
>> +                       interrupt-parent = <&plic>;
>> +                       interrupts = <PLIC_INT_RTC_WAKEUP PLIC_INT_RTC_MATCH>;
> 
> Please group using angular brackets.
> 
>> +                       status = "disabled";
>>                  };
>>
>> +               usb: usb@20201000 {
>> +                       compatible = "microchip,mpfs-usb-host";
>> +                       reg = <0x0 0x20201000 0x0 0x1000>;
>> +                       reg-names = "mc","control";
>> +                       clocks = <&clkcfg CLK_USB>;
>> +                       interrupt-parent = <&plic>;
>> +                       interrupts = <PLIC_INT_USB_DMA PLIC_INT_USB_MC>;
> 
> Please group using angular brackets.
> 
>> +                       interrupt-names = "dma","mc";
>> +                       dr_mode = "host";
>> +                       status = "disabled";
>> +               };
>> +
> 
> Gr{oetje,eeting}s,
> 
>                          Geert
> 
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
> 
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like that.
>                                  -- Linus Torvalds
> 


WARNING: multiple messages have this Message-ID (diff)
From: <Conor.Dooley@microchip.com>
To: <geert@linux-m68k.org>
Cc: <linus.walleij@linaro.org>, <bgolaszewski@baylibre.com>,
	<robh+dt@kernel.org>, <jassisinghbrar@gmail.com>,
	<paul.walmsley@sifive.com>,  <palmer@dabbelt.com>,
	<aou@eecs.berkeley.edu>, <a.zummo@towertech.it>,
	<alexandre.belloni@bootlin.com>, <broonie@kernel.org>,
	<gregkh@linuxfoundation.org>, <Lewis.Hanly@microchip.com>,
	<Daire.McNamara@microchip.com>, <atish.patra@wdc.com>,
	<Ivan.Griffin@microchip.com>, <linux-gpio@vger.kernel.org>,
	<devicetree@vger.kernel.org>, <linux-kernel@vger.kernel.org>,
	<linux-i2c@vger.kernel.org>, <linux-riscv@lists.infradead.org>,
	<linux-crypto@vger.kernel.org>, <linux-rtc@vger.kernel.org>,
	<linux-spi@vger.kernel.org>, <linux-usb@vger.kernel.org>,
	<krzysztof.kozlowski@canonical.com>, <bin.meng@windriver.com>
Subject: Re: [PATCH 12/13] riscv: icicle-kit: update microchip icicle kit device tree
Date: Wed, 10 Nov 2021 14:19:51 +0000	[thread overview]
Message-ID: <0e379411-2469-8c78-1a3f-0645579a967c@microchip.com> (raw)
In-Reply-To: <CAMuHMdWEhJj0Cqt3sgGvgZe7JSFqBmTgtZRkom30NKqEW27NvQ@mail.gmail.com>

On 09/11/2021 09:04, Geert Uytterhoeven wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
> 
> Hi Conor,
> 
> On Mon, Nov 8, 2021 at 4:07 PM <conor.dooley@microchip.com> wrote:
>> From: Conor Dooley <conor.dooley@microchip.com>
>>
>> Update the device tree for the icicle kit by splitting it into a third part,
>> which contains peripherals in the fpga fabric, add new peripherals
>> (spi, qspi, gpio, rtc, pcie, system services, i2c), update parts of the memory
>> map which have been changed.
>>
>> Signed-off-by: Conor Dooley <conor.dooley@microchip.com>
> 
> Thanks for your patch!
> 
> Please split it into logical separated parts.
yeah, ive split it into several patches - one for the splitting into 3, 
one for the new defines, one for the changes to existing nodes and one 
for node additions.

> 
>> --- /dev/null
>> +++ b/arch/riscv/boot/dts/microchip/microchip-mpfs-fabric.dtsi
>> @@ -0,0 +1,21 @@
>> +// SPDX-License-Identifier: (GPL-2.0 OR MIT)
>> +/* Copyright (c) 2020-2021 Microchip Technology Inc */
>> +
>> +/ {
>> +       fpgadma: fpgadma@60020000 {
>> +               compatible = "microchip,mpfs-fpga-dma-uio";
>> +               #address-cells = <1>;
>> +               #size-cells = <0>;
>> +               reg = <0x0 0x60020000 0x0 0x1000>;
>> +               interrupt-parent = <&plic>;
>> +               interrupts = <PLIC_INT_FABRIC_F2H_2>;
>> +               status = "okay";
>> +       };
>> +
>> +       fpgalsram: fpga_lsram@61000000 {
>> +               compatible = "generic-uio";
>> +               reg = <0x0 0x61000000 0x0 0x0001000
>> +                       0x14 0x00000000 0x0 0x00010000>;
> 
> Please group by angular brackets, to increase readability, and support
> automatic validation:
> 
> <0x0 0x61000000 0x0 0x0001000>, <0x14 0x00000000 0x0 0x00010000>
> 
>> +               status = "okay";
>> +       };
> 
> Do we really want UIO nodes in upstream DT?
As I said in the replies to another patch this is my first time doing 
any upstreaming of a device tree, i didnt realise that this would be a 
problem.
> 
>> +};
>> diff --git a/arch/riscv/boot/dts/microchip/microchip-mpfs-icicle-kit.dts b/arch/riscv/boot/dts/microchip/microchip-mpfs-icicle-kit.dts
>> index fc1e5869df1b..4212129fcdf1 100644
>> --- a/arch/riscv/boot/dts/microchip/microchip-mpfs-icicle-kit.dts
>> +++ b/arch/riscv/boot/dts/microchip/microchip-mpfs-icicle-kit.dts
>> @@ -1,5 +1,5 @@
>>   // SPDX-License-Identifier: (GPL-2.0 OR MIT)
>> -/* Copyright (c) 2020 Microchip Technology Inc */
>> +/* Copyright (c) 2020-2021 Microchip Technology Inc */
>>
>>   /dts-v1/;
>>
>> @@ -13,72 +13,187 @@ / {
>>          compatible = "microchip,mpfs-icicle-kit", "microchip,mpfs";
>>
>>          aliases {
>> -               ethernet0 = &emac1;
>> -               serial0 = &serial0;
>> -               serial1 = &serial1;
>> -               serial2 = &serial2;
>> -               serial3 = &serial3;
>> +               mmuart0 = &mmuart0;
>> +               mmuart1 = &mmuart1;
>> +               mmuart2 = &mmuart2;
>> +               mmuart3 = &mmuart3;
>> +               mmuart4 = &mmuart4;
> 
> Why? SerialN is the standard alias name.
we changed the label to mmuart to match the microchip documentation. 
would it make more sense to call mmuart but alias it to serial?
ie serial0 = &mmuart0;
> 
>>          };
> 
>>
>> -&emac0 {
>> +&spi0 {
>> +       status = "okay";
>> +       spidev@0 {
>> +               compatible = "spidev";
> 
> Please don't use "spidev", but a proper compatible value describing
> what is really connected.  If you want to use it with spidev (which
> is software policy, not hardware description), add that compatible
> value to drivers/spi/spidev.c:spidev_dt_ids[], or use driver_override
> in sysfs at runtime.
as i said to Krzysztof - this one was an oversight from me, that 
compatible has never been "spidev"  on its own in our internal tree and 
i mustve accidentally omitted the vendor string while making these patches.

Either way, after talking some more we decided that this entry is not 
appropriate anyway and i will drop it.
> 
>> +               reg = <0>; /* CS 0 */
>> +               spi-max-frequency = <10000000>;
>> +               status = "okay";
>> +       };
>> +};
>> +
>> +&spi1 {
>> +       status = "okay";
> 
> No slave devices specified?
no, but its exposed
> 
>> +};
>> +
>> +&qspi {
>> +       status = "okay";
>> +};
>> +
>> +&i2c0 {
>> +       status = "okay";
>> +};
>> +
>> +&i2c1 {
>> +       status = "okay";
>> +       pac193x: pac193x@10 {
> 
> adc@, I guess?
sure
> 
>> +               compatible = "microchip,pac1934";
>> +               reg = <0x10>;
>> +               samp-rate = <64>;
>> +               status = "okay";
>> +               ch0: channel0 {
>> +                       uohms-shunt-res = <10000>;
>> +                       rail-name = "VDDREG";
>> +                       channel_enabled;
>> +               };
>> +               ch1: channel1 {
>> +                       uohms-shunt-res = <10000>;
>> +                       rail-name = "VDDA25";
>> +                       channel_enabled;
>> +               };
>> +               ch2: channel2 {
>> +                       uohms-shunt-res = <10000>;
>> +                       rail-name = "VDD25";
>> +                       channel_enabled;
>> +               };
>> +               ch3: channel3 {
>> +                       uohms-shunt-res = <10000>;
>> +                       rail-name = "VDDA_REG";
>> +                       channel_enabled;
>> +               };
>> +       };
>> +};
> 
>> +&gpio2 {
>> +       interrupts = <PLIC_INT_GPIO2_NON_DIRECT
>> +               PLIC_INT_GPIO2_NON_DIRECT
>> +               PLIC_INT_GPIO2_NON_DIRECT
>> +               PLIC_INT_GPIO2_NON_DIRECT
>> +               PLIC_INT_GPIO2_NON_DIRECT
>> +               PLIC_INT_GPIO2_NON_DIRECT
>> +               PLIC_INT_GPIO2_NON_DIRECT
>> +               PLIC_INT_GPIO2_NON_DIRECT
>> +               PLIC_INT_GPIO2_NON_DIRECT
>> +               PLIC_INT_GPIO2_NON_DIRECT
>> +               PLIC_INT_GPIO2_NON_DIRECT
>> +               PLIC_INT_GPIO2_NON_DIRECT
>> +               PLIC_INT_GPIO2_NON_DIRECT
>> +               PLIC_INT_GPIO2_NON_DIRECT
>> +               PLIC_INT_GPIO2_NON_DIRECT
>> +               PLIC_INT_GPIO2_NON_DIRECT
>> +               PLIC_INT_GPIO2_NON_DIRECT
>> +               PLIC_INT_GPIO2_NON_DIRECT
>> +               PLIC_INT_GPIO2_NON_DIRECT
>> +               PLIC_INT_GPIO2_NON_DIRECT
>> +               PLIC_INT_GPIO2_NON_DIRECT
>> +               PLIC_INT_GPIO2_NON_DIRECT
>> +               PLIC_INT_GPIO2_NON_DIRECT
>> +               PLIC_INT_GPIO2_NON_DIRECT
>> +               PLIC_INT_GPIO2_NON_DIRECT
>> +               PLIC_INT_GPIO2_NON_DIRECT
>> +               PLIC_INT_GPIO2_NON_DIRECT
>> +               PLIC_INT_GPIO2_NON_DIRECT
>> +               PLIC_INT_GPIO2_NON_DIRECT
>> +               PLIC_INT_GPIO2_NON_DIRECT
>> +               PLIC_INT_GPIO2_NON_DIRECT
>> +               PLIC_INT_GPIO2_NON_DIRECT>;
> 
> Why override interrupts in the board .dts file?
> Doesn't this belong in the SoC .dtsi file?
The interrupt setup for the gpio isnt fixed, there is an option to 
either connect the individual gpio interrupts to the plic *or* they can 
be connected to a per gpio controller common interrupt, and it is up to 
the driver to read a register to determine which interrupt triggered the 
common/NON_DIRECT interrupt. This decision is made by a write to a 
system register in application code, which to us didn't seem like it 
belonged in the soc .dtsi.

Using the common interrupt for GPIO2 is the default on the 
polarfire-soc, there are only 38 per gpio line interrupts available of 
which 14 are connected to gpio0 and 24 to gpio1.

> Please group using angular brackets.
> 
>> --- a/arch/riscv/boot/dts/microchip/microchip-mpfs.dtsi
>> +++ b/arch/riscv/boot/dts/microchip/microchip-mpfs.dtsi
> 
>> @@ -145,49 +149,55 @@ cpu4_intc: interrupt-controller {
>>          soc {
>>                  #address-cells = <2>;
>>                  #size-cells = <2>;
>> -               compatible = "simple-bus";
>> +               compatible = "microchip,mpfs-soc", "simple-bus";
>>                  ranges;
>>
>> -               cache-controller@2010000 {
>> +               cctrllr: cache-controller@2010000 {
>>                          compatible = "sifive,fu540-c000-ccache", "cache";
>> +                       reg = <0x0 0x2010000 0x0 0x1000>;
>> +                       interrupt-parent = <&plic>;
>> +                       interrupts = <PLIC_INT_L2_METADATA_CORR
>> +                               PLIC_INT_L2_METADAT_UNCORR
>> +                               PLIC_INT_L2_DATA_CORR>;
> 
> Please group using angular brackets.
> 
>>                          cache-block-size = <64>;
>>                          cache-level = <2>;
>>                          cache-sets = <1024>;
>>                          cache-size = <2097152>;
>>                          cache-unified;
>> -                       interrupt-parent = <&plic>;
>> -                       interrupts = <1 2 3>;
>> -                       reg = <0x0 0x2010000 0x0 0x1000>;
>>                  };
>>
>> -               clint@2000000 {
>> +               clint: clint@2000000 {
>>                          compatible = "sifive,fu540-c000-clint", "sifive,clint0";
>>                          reg = <0x0 0x2000000 0x0 0xC000>;
>> -                       interrupts-extended = <&cpu0_intc 3 &cpu0_intc 7
>> -                                               &cpu1_intc 3 &cpu1_intc 7
>> -                                               &cpu2_intc 3 &cpu2_intc 7
>> -                                               &cpu3_intc 3 &cpu3_intc 7
>> -                                               &cpu4_intc 3 &cpu4_intc 7>;
>> +                       interrupts-extended =
>> +                                       <&cpu0_intc HART_INT_M_SOFT &cpu0_intc HART_INT_M_TIMER
>> +                                        &cpu1_intc HART_INT_M_SOFT &cpu1_intc HART_INT_M_TIMER
>> +                                        &cpu2_intc HART_INT_M_SOFT &cpu2_intc HART_INT_M_TIMER
>> +                                        &cpu3_intc HART_INT_M_SOFT &cpu3_intc HART_INT_M_TIMER
>> +                                        &cpu4_intc HART_INT_M_SOFT &cpu4_intc HART_INT_M_TIMER>;
> 
> Please group using angular brackets.
> 
>>                  };
>>
>>                  plic: interrupt-controller@c000000 {
>> -                       #interrupt-cells = <1>;
>> -                       compatible = "sifive,fu540-c000-plic", "sifive,plic-1.0.0";
>> +                       compatible = "sifive,plic-1.0.0";
> 
> Why drop the first one again?
we felt it didnt make sense to have something that specifically 
references the fu540 in the device tree for this board.
> 
>>                          reg = <0x0 0xc000000 0x0 0x4000000>;
>> +                       #interrupt-cells = <1>;
>>                          riscv,ndev = <186>;
>>                          interrupt-controller;
>> -                       interrupts-extended = <&cpu0_intc 11
>> -                                       &cpu1_intc 11 &cpu1_intc 9
>> -                                       &cpu2_intc 11 &cpu2_intc 9
>> -                                       &cpu3_intc 11 &cpu3_intc 9
>> -                                       &cpu4_intc 11 &cpu4_intc 9>;
>> +                       interrupts-extended = <&cpu0_intc HART_INT_M_EXT
>> +                                       &cpu1_intc HART_INT_M_EXT &cpu1_intc HART_INT_S_EXT
>> +                                       &cpu2_intc HART_INT_M_EXT &cpu2_intc HART_INT_S_EXT
>> +                                       &cpu3_intc HART_INT_M_EXT &cpu3_intc HART_INT_S_EXT
>> +                                       &cpu4_intc HART_INT_M_EXT &cpu4_intc HART_INT_S_EXT>;
>>                  };
>>
>> -               dma@3000000 {
>> -                       compatible = "sifive,fu540-c000-pdma";
>> +               pdma: pdma@3000000 {
>> +                       compatible = "microchip,mpfs-pdma-uio";
>>                          reg = <0x0 0x3000000 0x0 0x8000>;
>>                          interrupt-parent = <&plic>;
>> -                       interrupts = <23 24 25 26 27 28 29 30>;
>> +                       interrupts = <PLIC_INT_DMA_CH0_DONE PLIC_INT_DMA_CH0_ERR
>> +                               PLIC_INT_DMA_CH1_DONE PLIC_INT_DMA_CH1_ERR
>> +                               PLIC_INT_DMA_CH2_DONE PLIC_INT_DMA_CH2_ERR
>> +                               PLIC_INT_DMA_CH3_DONE PLIC_INT_DMA_CH3_ERR>;
> 
> Please group using angular brackets.
> 
>>                          #dma-cells = <1>;
>>                  };
>>
>> @@ -205,7 +215,7 @@ clkcfg: clkcfg@20002000 {
>>                          clocks = <&refclk>;
>>                          #clock-cells = <1>;
>>                          clock-output-names = "cpu", "axi", "ahb", "envm",       /* 0-3   */
>> -                                "mac0", "mac1", "mmc", "timer",                /* 4-7   */
>> +                               "mac0", "mac1", "mmc", "timer",                 /* 4-7   */
>>                                  "mmuart0", "mmuart1", "mmuart2", "mmuart3",     /* 8-11  */
>>                                  "mmuart4", "spi0", "spi1", "i2c0",              /* 12-15 */
>>                                  "i2c1", "can0", "can1", "usb",                  /* 16-19 */
> 
> No need for clock-output-names at all.
> 
>>
>> -               emac1: ethernet@20112000 {
>> +               mac0: ethernet@20110000 {
>>                          compatible = "cdns,macb";
>> -                       reg = <0x0 0x20112000 0x0 0x2000>;
>> +                       #address-cells = <1>;
>> +                       #size-cells = <0>;
>> +                       reg = <0x0 0x20110000 0x0 0x2000>;
>> +                       clocks = <&clkcfg CLK_MAC0>, <&clkcfg CLK_AHB>;
>> +                       clock-names = "pclk", "hclk";
>>                          interrupt-parent = <&plic>;
>> -                       interrupts = <70 71 72 73>;
>> -                       local-mac-address = [00 00 00 00 00 00];
>> -                       clocks = <&clkcfg 5>, <&clkcfg 2>;
>> +                       interrupts = <PLIC_INT_MAC0_INT
>> +                               PLIC_INT_MAC0_QUEUE1
>> +                               PLIC_INT_MAC0_QUEUE2
>> +                               PLIC_INT_MAC0_QUEUE3
>> +                               PLIC_INT_MAC0_EMAC
>> +                               PLIC_INT_MAC0_MMSL>;
> 
> Please group using angular brackets.
> 
>> +                       mac-address = [56 34 12 00 FC 01];
> 
> Please drop this.
Is the problem here having mac-address instead of local-, having either 
at all or that we have populated it rather than just filling with 0s?
We set it in u-boot anyway, so I think dropping entirely is okay.
> 
>>                          status = "disabled";
>> +               };
>>
>> +               rtc: rtc@20124000 {
>> +                       compatible = "microchip,mpfs-rtc";
>>                          #address-cells = <1>;
>>                          #size-cells = <0>;
>> +                       reg = <0x0 0x20124000 0x0 0x1000>;
>> +                       clocks = <&clkcfg CLK_RTC>;
>> +                       clock-names = "rtc";
>> +                       interrupt-parent = <&plic>;
>> +                       interrupts = <PLIC_INT_RTC_WAKEUP PLIC_INT_RTC_MATCH>;
> 
> Please group using angular brackets.
> 
>> +                       status = "disabled";
>>                  };
>>
>> +               usb: usb@20201000 {
>> +                       compatible = "microchip,mpfs-usb-host";
>> +                       reg = <0x0 0x20201000 0x0 0x1000>;
>> +                       reg-names = "mc","control";
>> +                       clocks = <&clkcfg CLK_USB>;
>> +                       interrupt-parent = <&plic>;
>> +                       interrupts = <PLIC_INT_USB_DMA PLIC_INT_USB_MC>;
> 
> Please group using angular brackets.
> 
>> +                       interrupt-names = "dma","mc";
>> +                       dr_mode = "host";
>> +                       status = "disabled";
>> +               };
>> +
> 
> Gr{oetje,eeting}s,
> 
>                          Geert
> 
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
> 
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like that.
>                                  -- Linus Torvalds
> 

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

  reply	other threads:[~2021-11-10 14:20 UTC|newest]

Thread overview: 140+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-11-08 15:05 [PATCH 00/13]Update the icicle kit device tree conor.dooley
2021-11-08 15:05 ` conor.dooley
2021-11-08 15:05 ` [PATCH 01/13] dt-bindings: interrupt-controller: create a header for RISC-V interrupts conor.dooley
2021-11-08 15:05   ` conor.dooley
2021-11-23 11:07   ` Heiko Stübner
2021-11-23 11:07     ` Heiko Stübner
2021-11-23 11:35     ` Anup Patel
2021-11-23 11:35       ` Anup Patel
2021-11-29 19:57   ` Rob Herring
2021-11-29 19:57     ` Rob Herring
2021-11-08 15:05 ` [PATCH 02/13] dt-bindings: interrupt-controller: add defines for mpfs-plic conor.dooley
2021-11-08 15:05   ` conor.dooley
2021-11-23 11:17   ` Heiko Stübner
2021-11-23 11:17     ` Heiko Stübner
2021-11-29 19:56   ` Rob Herring
2021-11-29 19:56     ` Rob Herring
2021-11-30  8:15     ` Conor.Dooley
2021-11-30  8:15       ` Conor.Dooley
2021-11-08 15:05 ` [PATCH 03/13] dt-bindings: soc/microchip: update sys ctrlr compat string conor.dooley
2021-11-08 15:05   ` conor.dooley
2021-11-08 21:09   ` Krzysztof Kozlowski
2021-11-08 21:09     ` Krzysztof Kozlowski
2021-11-09  8:33   ` Geert Uytterhoeven
2021-11-09  8:33     ` Geert Uytterhoeven
2021-11-09 15:20     ` Conor.Dooley
2021-11-09 15:20       ` Conor.Dooley
2021-11-29 20:03   ` Rob Herring
2021-11-29 20:03     ` Rob Herring
2021-11-30  8:35     ` Conor.Dooley
2021-11-30  8:35       ` Conor.Dooley
2021-11-08 15:05 ` [PATCH 04/13] dt-bindings: riscv: update microchip polarfire binds conor.dooley
2021-11-08 15:05   ` conor.dooley
2021-11-08 21:10   ` Krzysztof Kozlowski
2021-11-08 21:10     ` Krzysztof Kozlowski
2021-11-09  8:34   ` Geert Uytterhoeven
2021-11-09  8:34     ` Geert Uytterhoeven
2021-11-09 12:08     ` Conor.Dooley
2021-11-09 12:08       ` Conor.Dooley
2021-11-09 13:04       ` Geert Uytterhoeven
2021-11-09 13:04         ` Geert Uytterhoeven
2021-11-23 11:24         ` Heiko Stübner
2021-11-23 11:24           ` Heiko Stübner
2021-11-08 15:05 ` [PATCH 05/13] dt-bindings: i2c: add bindings for microchip mpfs i2c conor.dooley
2021-11-08 15:05   ` conor.dooley
2021-11-08 21:13   ` Krzysztof Kozlowski
2021-11-08 21:13     ` Krzysztof Kozlowski
2021-11-09  4:06   ` Rob Herring
2021-11-09  4:06     ` Rob Herring
2021-11-08 15:05 ` [PATCH 06/13] dt-bindings: rng: add bindings for microchip mpfs rng conor.dooley
2021-11-08 15:05   ` conor.dooley
2021-11-08 21:16   ` Krzysztof Kozlowski
2021-11-08 21:16     ` Krzysztof Kozlowski
2021-11-09 12:54     ` Conor.Dooley
2021-11-09 12:54       ` Conor.Dooley
2021-11-09 12:56       ` Krzysztof Kozlowski
2021-11-09 12:56         ` Krzysztof Kozlowski
2021-11-09 13:36         ` Conor.Dooley
2021-11-09 13:36           ` Conor.Dooley
2021-11-10  7:43           ` Krzysztof Kozlowski
2021-11-10  7:43             ` Krzysztof Kozlowski
2021-11-10  9:46             ` Conor.Dooley
2021-11-10  9:46               ` Conor.Dooley
2021-11-29 20:08               ` Rob Herring
2021-11-29 20:08                 ` Rob Herring
2021-11-09  8:37   ` Geert Uytterhoeven
2021-11-09  8:37     ` Geert Uytterhoeven
2021-11-09 11:55     ` Conor.Dooley
2021-11-09 11:55       ` Conor.Dooley
2021-11-08 15:05 ` [PATCH 07/13] dt-bindings: rtc: add bindings for microchip mpfs rtc conor.dooley
2021-11-08 15:05   ` conor.dooley
2021-11-08 21:20   ` Krzysztof Kozlowski
2021-11-08 21:20     ` Krzysztof Kozlowski
2021-11-09  4:06   ` Rob Herring
2021-11-09  4:06     ` Rob Herring
2021-11-09  8:39   ` Geert Uytterhoeven
2021-11-09  8:39     ` Geert Uytterhoeven
2021-11-08 15:05 ` [PATCH 08/13] dt-bindings: soc/microchip: add bindings for mpfs system services conor.dooley
2021-11-08 15:05   ` conor.dooley
2021-11-08 21:20   ` Krzysztof Kozlowski
2021-11-08 21:20     ` Krzysztof Kozlowski
2021-11-08 15:05 ` [PATCH 09/13] dt-bindings: gpio: add bindings for microchip mpfs gpio conor.dooley
2021-11-08 15:05   ` conor.dooley
2021-11-08 21:22   ` Krzysztof Kozlowski
2021-11-08 21:22     ` Krzysztof Kozlowski
2021-11-09  4:06   ` Rob Herring
2021-11-09  4:06     ` Rob Herring
2021-11-09  8:43   ` Geert Uytterhoeven
2021-11-09  8:43     ` Geert Uytterhoeven
2021-11-08 15:05 ` [PATCH 10/13] dt-bindings: spi: add bindings for microchip mpfs spi conor.dooley
2021-11-08 15:05   ` conor.dooley
2021-11-08 21:24   ` Krzysztof Kozlowski
2021-11-08 21:24     ` Krzysztof Kozlowski
2021-11-09  4:06   ` Rob Herring
2021-11-09  4:06     ` Rob Herring
2021-11-09 12:16     ` Conor.Dooley
2021-11-09 12:16       ` Conor.Dooley
2021-11-09 12:53       ` Krzysztof Kozlowski
2021-11-09 12:53         ` Krzysztof Kozlowski
2021-11-09 12:58         ` Conor.Dooley
2021-11-09 12:58           ` Conor.Dooley
2021-11-09 13:04           ` Krzysztof Kozlowski
2021-11-09 13:04             ` Krzysztof Kozlowski
2021-11-09 13:20             ` Conor.Dooley
2021-11-09 13:20               ` Conor.Dooley
2021-11-10  7:45               ` Krzysztof Kozlowski
2021-11-10  7:45                 ` Krzysztof Kozlowski
2021-11-09  8:45   ` Geert Uytterhoeven
2021-11-09  8:45     ` Geert Uytterhoeven
2021-11-09 10:56     ` Conor.Dooley
2021-11-09 10:56       ` Conor.Dooley
2021-11-08 15:05 ` [PATCH 11/13] dt-bindings: usb: add bindings for microchip mpfs musb conor.dooley
2021-11-08 15:05   ` conor.dooley
2021-11-08 21:27   ` Krzysztof Kozlowski
2021-11-08 21:27     ` Krzysztof Kozlowski
2021-11-09  4:06   ` Rob Herring
2021-11-09  4:06     ` Rob Herring
2021-11-09  8:48   ` Geert Uytterhoeven
2021-11-09  8:48     ` Geert Uytterhoeven
2021-11-08 15:05 ` [PATCH 12/13] riscv: icicle-kit: update microchip icicle kit device tree conor.dooley
2021-11-08 15:05   ` conor.dooley
2021-11-08 21:40   ` Krzysztof Kozlowski
2021-11-08 21:40     ` Krzysztof Kozlowski
2021-11-10 12:07     ` Conor.Dooley
2021-11-10 12:07       ` Conor.Dooley
2021-11-09  9:04   ` Geert Uytterhoeven
2021-11-09  9:04     ` Geert Uytterhoeven
2021-11-10 14:19     ` Conor.Dooley [this message]
2021-11-10 14:19       ` Conor.Dooley
2021-11-10 14:58       ` Geert Uytterhoeven
2021-11-10 14:58         ` Geert Uytterhoeven
2021-11-10 15:07         ` Conor.Dooley
2021-11-10 15:07           ` Conor.Dooley
2021-11-15 15:39         ` Conor.Dooley
2021-11-15 15:39           ` Conor.Dooley
2021-11-15 16:17           ` Geert Uytterhoeven
2021-11-15 16:17             ` Geert Uytterhoeven
2021-11-17 12:17             ` Daire.McNamara
2021-11-17 12:17               ` Daire.McNamara
2021-11-08 15:05 ` [PATCH 13/13] MAINTAINERS: update riscv/microchip entry conor.dooley
2021-11-08 15:05   ` 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=0e379411-2469-8c78-1a3f-0645579a967c@microchip.com \
    --to=conor.dooley@microchip.com \
    --cc=Daire.McNamara@microchip.com \
    --cc=Ivan.Griffin@microchip.com \
    --cc=Lewis.Hanly@microchip.com \
    --cc=a.zummo@towertech.it \
    --cc=alexandre.belloni@bootlin.com \
    --cc=aou@eecs.berkeley.edu \
    --cc=atish.patra@wdc.com \
    --cc=bgolaszewski@baylibre.com \
    --cc=bin.meng@windriver.com \
    --cc=broonie@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=geert@linux-m68k.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=jassisinghbrar@gmail.com \
    --cc=krzysztof.kozlowski@canonical.com \
    --cc=linus.walleij@linaro.org \
    --cc=linux-crypto@vger.kernel.org \
    --cc=linux-gpio@vger.kernel.org \
    --cc=linux-i2c@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-riscv@lists.infradead.org \
    --cc=linux-rtc@vger.kernel.org \
    --cc=linux-spi@vger.kernel.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=palmer@dabbelt.com \
    --cc=paul.walmsley@sifive.com \
    --cc=robh+dt@kernel.org \
    /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.