[PATCH v3 0/3] Add RZ/N1 CAN support

[PATCH v3 0/3] Add RZ/N1 CAN support

[Biju Das]

This patch series supports CAN{0,1} populated on RZ/N1D-DB board.

v2->v3:
 * Documented power-domains support.
 * Dropped clock-names property from CAN nodes.
 * Added power-domains property to the CAN nodes.
v1->v2:
 * Added RZ/N1 specific compatible string.
 * Added clock-names property.

This patch series depend upon [1]
[1] https://lore.kernel.org/linux-renesas-soc/20220819084532.ywtziogd7ycuozxx@pengutronix.de/

Biju Das (3):
  dt-bindings: can: nxp,sja1000: Document RZ/N1 power-domains support
  ARM: dts: r9a06g032: Add CAN{0,1} nodes
  ARM: dts: r9a06g032-rzn1d400-db: Enable CAN{0,1}

 .../bindings/net/can/nxp,sja1000.yaml         |  5 ++++
 arch/arm/boot/dts/r9a06g032-rzn1d400-db.dts   | 26 +++++++++++++++++++
 arch/arm/boot/dts/r9a06g032.dtsi              | 20 ++++++++++++++
 3 files changed, 51 insertions(+)

-- 
2.25.1

[PATCH v3 1/3] dt-bindings: can: nxp,sja1000: Document RZ/N1 power-domains support

[Biju Das]

Document RZ/N1 power-domains support. Also update the example with
power-domains property.

Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com>
---
v3:
 * Documented power-domains support.
---
 Documentation/devicetree/bindings/net/can/nxp,sja1000.yaml | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/Documentation/devicetree/bindings/net/can/nxp,sja1000.yaml b/Documentation/devicetree/bindings/net/can/nxp,sja1000.yaml
index b1327c5b86cf..5b588726853f 100644
--- a/Documentation/devicetree/bindings/net/can/nxp,sja1000.yaml
+++ b/Documentation/devicetree/bindings/net/can/nxp,sja1000.yaml
@@ -30,6 +30,9 @@ properties:
   clocks:
     maxItems: 1
 
+  power-domains:
+    maxItems: 1
+
   reg-io-width:
     $ref: /schemas/types.yaml#/definitions/uint32
     description: I/O register width (in bytes) implemented by this device
@@ -105,6 +108,7 @@ allOf:
     then:
       required:
         - clocks
+        - power-domains
 
 unevaluatedProperties: false
 
@@ -129,4 +133,5 @@ examples:
         reg-io-width = <4>;
         interrupts = <GIC_SPI 95 IRQ_TYPE_LEVEL_HIGH>;
         clocks = <&sysctrl R9A06G032_HCLK_CAN0>;
+        power-domains = <&sysctrl>;
     };
-- 
2.25.1

Re: [PATCH v3 1/3] dt-bindings: can: nxp,sja1000: Document RZ/N1 power-domains support

[Krzysztof Kozlowski]

On 30/08/2022 19:45, Biju Das wrote:
> Document RZ/N1 power-domains support. Also update the example with
> power-domains property.
> 
> Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com>
> ---
> v3:
>  * Documented power-domains support.

You made them required, so it would be nice to see reason in such
change. The commit msg says only what you did, but not why you did it.

Best regards,
Krzysztof

RE: [PATCH v3 1/3] dt-bindings: can: nxp,sja1000: Document RZ/N1 power-domains support

[Biju Das]

Hi Krzysztof Kozlowski,

Thanks for the feedback.

> Subject: Re: [PATCH v3 1/3] dt-bindings: can: nxp,sja1000: Document
> RZ/N1 power-domains support
> 
> On 30/08/2022 19:45, Biju Das wrote:
> > Document RZ/N1 power-domains support. Also update the example with
> > power-domains property.
> >
> > Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com>
> > ---
> > v3:
> >  * Documented power-domains support.
> 
> You made them required, so it would be nice to see reason in such
> change. The commit msg says only what you did, but not why you did it.

It is simple. As you see from [1] and [2] power-domains are enabled by default in RZ/N1 SoC.
So there is nothing prevent us to document this property for all IP's present in
RZ/N1 SoC.

[1]https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/drivers/clk/renesas/r9a06g032-clocks.c?h=v6.0-rc3&id=aad03a66f902e18bab612870261bde647fdbda2c

[2] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/drivers/soc/renesas?h=v6.0-rc3&id=14f11da778ff642142e9be18814815754c82d6c5

Cheers,
Biju

Re: [PATCH v3 1/3] dt-bindings: can: nxp,sja1000: Document RZ/N1 power-domains support

[Krzysztof Kozlowski]

On 30/08/2022 20:47, Biju Das wrote:
> Hi Krzysztof Kozlowski,
> 
> Thanks for the feedback.
> 
>> Subject: Re: [PATCH v3 1/3] dt-bindings: can: nxp,sja1000: Document
>> RZ/N1 power-domains support
>>
>> On 30/08/2022 19:45, Biju Das wrote:
>>> Document RZ/N1 power-domains support. Also update the example with
>>> power-domains property.
>>>
>>> Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com>
>>> ---
>>> v3:
>>>  * Documented power-domains support.
>>
>> You made them required, so it would be nice to see reason in such
>> change. The commit msg says only what you did, but not why you did it.
> 
> It is simple. As you see from [1] and [2] power-domains are enabled by default in RZ/N1 SoC.
> So there is nothing prevent us to document this property for all IP's present in
> RZ/N1 SoC.

Any explanation I expect to see in commit msg.

Anyway you referred to Linux drivers, which is not actually a reason.
What if some device is not in a power domain?

Best regards,
Krzysztof

Re: [PATCH v3 1/3] dt-bindings: can: nxp,sja1000: Document RZ/N1 power-domains support

[Geert Uytterhoeven]

Hi Krzysztof,

On Tue, Aug 30, 2022 at 9:03 PM Krzysztof Kozlowski
<krzysztof.kozlowski@linaro.org> wrote:
> On 30/08/2022 20:47, Biju Das wrote:
> >> Subject: Re: [PATCH v3 1/3] dt-bindings: can: nxp,sja1000: Document
> >> RZ/N1 power-domains support
> >>
> >> On 30/08/2022 19:45, Biju Das wrote:
> >>> Document RZ/N1 power-domains support. Also update the example with
> >>> power-domains property.
> >>>
> >>> Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com>
> >>> ---
> >>> v3:
> >>>  * Documented power-domains support.
> >>
> >> You made them required, so it would be nice to see reason in such
> >> change. The commit msg says only what you did, but not why you did it.
> >
> > It is simple. As you see from [1] and [2] power-domains are enabled by default in RZ/N1 SoC.
> > So there is nothing prevent us to document this property for all IP's present in
> > RZ/N1 SoC.
>
> Any explanation I expect to see in commit msg.
>
> Anyway you referred to Linux drivers, which is not actually a reason.
> What if some device is not in a power domain?

DT describes hardware, not software policy.

"power domains" are a property of the hardware.
I.e. this device (like most other devices on the SoC) is power-managed
through the system-controller.

Whether software does that by explicitly managing the clocks, or by
having a PM Domains driver is a software detail.

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

Re: [PATCH v3 1/3] dt-bindings: can: nxp,sja1000: Document RZ/N1 power-domains support

[Geert Uytterhoeven]

On Tue, Aug 30, 2022 at 6:45 PM Biju Das <biju.das.jz@bp.renesas.com> wrote:
> Document RZ/N1 power-domains support. Also update the example with
> power-domains property.
>
> Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com>
> ---
> v3:
>  * Documented power-domains support.

Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>

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

[PATCH v3 2/3] ARM: dts: r9a06g032: Add CAN{0,1} nodes

[Biju Das]

Add CAN{0,1} nodes to R9A06G032 (RZ/N1) SoC DTSI.

Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com>
---
v2->v3:
 * Dropped clock-names property.
 * Added power-domains property.
v1->v2:
 * Added RZ/N1 specific compatible string.
 * Added clock-names property.
---
 arch/arm/boot/dts/r9a06g032.dtsi | 20 ++++++++++++++++++++
 1 file changed, 20 insertions(+)

diff --git a/arch/arm/boot/dts/r9a06g032.dtsi b/arch/arm/boot/dts/r9a06g032.dtsi
index 5b97fa85474f..563024c9a4ae 100644
--- a/arch/arm/boot/dts/r9a06g032.dtsi
+++ b/arch/arm/boot/dts/r9a06g032.dtsi
@@ -423,6 +423,26 @@ gic: interrupt-controller@44101000 {
 			interrupts =
 				<GIC_PPI 9 (GIC_CPU_MASK_SIMPLE(2) | IRQ_TYPE_LEVEL_HIGH)>;
 		};
+
+		can0: can@52104000 {
+			compatible = "renesas,r9a06g032-sja1000","renesas,rzn1-sja1000";
+			reg = <0x52104000 0x800>;
+			reg-io-width = <4>;
+			interrupts = <GIC_SPI 95 IRQ_TYPE_LEVEL_HIGH>;
+			clocks = <&sysctrl R9A06G032_HCLK_CAN0>;
+			power-domains = <&sysctrl>;
+			status = "disabled";
+		};
+
+		can1: can@52105000 {
+			compatible = "renesas,r9a06g032-sja1000", "renesas,rzn1-sja1000";
+			reg = <0x52105000 0x800>;
+			reg-io-width = <4>;
+			interrupts = <GIC_SPI 96 IRQ_TYPE_LEVEL_HIGH>;
+			clocks = <&sysctrl R9A06G032_HCLK_CAN1>;
+			power-domains = <&sysctrl>;
+			status = "disabled";
+		};
 	};
 
 	timer {
-- 
2.25.1

Re: [PATCH v3 2/3] ARM: dts: r9a06g032: Add CAN{0,1} nodes

[Geert Uytterhoeven]

On Tue, Aug 30, 2022 at 6:45 PM Biju Das <biju.das.jz@bp.renesas.com> wrote:
> Add CAN{0,1} nodes to R9A06G032 (RZ/N1) SoC DTSI.
>
> Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com>
> ---
> v2->v3:
>  * Dropped clock-names property.
>  * Added power-domains property.

Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
i.e. will queue in renesas-devel for v6.1.

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

[PATCH v3 3/3] ARM: dts: r9a06g032-rzn1d400-db: Enable CAN{0,1}

[Biju Das]

Enable CAN{0,1} on RZ/N1D-DB board.

Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com>
---
v2->v3:
 * No change
v1->v2:
 * No change
---
 arch/arm/boot/dts/r9a06g032-rzn1d400-db.dts | 26 +++++++++++++++++++++
 1 file changed, 26 insertions(+)

diff --git a/arch/arm/boot/dts/r9a06g032-rzn1d400-db.dts b/arch/arm/boot/dts/r9a06g032-rzn1d400-db.dts
index 4bf813335e21..49104c73eca3 100644
--- a/arch/arm/boot/dts/r9a06g032-rzn1d400-db.dts
+++ b/arch/arm/boot/dts/r9a06g032-rzn1d400-db.dts
@@ -26,6 +26,20 @@ aliases {
 	};
 };
 
+&can0 {
+	pinctrl-0 = <&pins_can0>;
+	pinctrl-names = "default";
+
+	status = "okay";
+};
+
+&can1 {
+	pinctrl-0 = <&pins_can1>;
+	pinctrl-names = "default";
+
+	status = "okay";
+};
+
 &eth_miic {
 	status = "okay";
 	renesas,miic-switch-portin = <MIIC_GMAC2_PORT>;
@@ -52,6 +66,18 @@ &mii_conv5 {
 };
 
 &pinctrl{
+	pins_can0: pins_can0 {
+		pinmux = <RZN1_PINMUX(162, RZN1_FUNC_CAN)>,	/* CAN0_TXD */
+			 <RZN1_PINMUX(163, RZN1_FUNC_CAN)>;	/* CAN0_RXD */
+		drive-strength = <6>;
+	};
+
+	pins_can1: pins_can1 {
+		pinmux = <RZN1_PINMUX(109, RZN1_FUNC_CAN)>,	/* CAN1_TXD */
+			 <RZN1_PINMUX(110, RZN1_FUNC_CAN)>;	/* CAN1_RXD */
+		drive-strength = <6>;
+	};
+
 	pins_eth3: pins_eth3 {
 		pinmux = <RZN1_PINMUX(36, RZN1_FUNC_CLK_ETH_MII_RGMII_RMII)>,
 			 <RZN1_PINMUX(37, RZN1_FUNC_CLK_ETH_MII_RGMII_RMII)>,
-- 
2.25.1

Re: [PATCH v3 3/3] ARM: dts: r9a06g032-rzn1d400-db: Enable CAN{0,1}

[Geert Uytterhoeven]

Hi Biju,

On Tue, Aug 30, 2022 at 6:45 PM Biju Das <biju.das.jz@bp.renesas.com> wrote:
> Enable CAN{0,1} on RZ/N1D-DB board.
>
> Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com>
> ---
> v2->v3:
>  * No change

Thanks for your patch!

> --- a/arch/arm/boot/dts/r9a06g032-rzn1d400-db.dts
> +++ b/arch/arm/boot/dts/r9a06g032-rzn1d400-db.dts
> @@ -26,6 +26,20 @@ aliases {
>         };
>  };
>
> +&can0 {
> +       pinctrl-0 = <&pins_can0>;
> +       pinctrl-names = "default";
> +
> +       status = "okay";
> +};
> +
> +&can1 {
> +       pinctrl-0 = <&pins_can1>;
> +       pinctrl-names = "default";
> +
> +       status = "okay";
> +};

According to the schematics and board documentation, only a single CAN
connector is present, and the CAN interface to use must be selected
using the CN10/CN11 jumpers.  Hence I think we need a #define and
an #ifdef to configure this, or at least keep one interface disabled,
and add a comment explaining why.

The rest LGTM.

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

RE: [PATCH v3 3/3] ARM: dts: r9a06g032-rzn1d400-db: Enable CAN{0,1}

[Biju Das]

Hi Geert,

Thanks for the feedback.

> Subject: Re: [PATCH v3 3/3] ARM: dts: r9a06g032-rzn1d400-db: Enable
> CAN{0,1}
> 
> Hi Biju,
> 
> On Tue, Aug 30, 2022 at 6:45 PM Biju Das <biju.das.jz@bp.renesas.com>
> wrote:
> > Enable CAN{0,1} on RZ/N1D-DB board.

My bad, it is RZ/N1D-DB CPU board fitted to RZ/N1-EB carrier board.
Actually it enables CAN{0,1} on the carrier board.

> >
> > Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com>
> > ---
> > v2->v3:
> >  * No change
> 
> Thanks for your patch!
> 
> > --- a/arch/arm/boot/dts/r9a06g032-rzn1d400-db.dts
> > +++ b/arch/arm/boot/dts/r9a06g032-rzn1d400-db.dts
> > @@ -26,6 +26,20 @@ aliases {
> >         };
> >  };
> >
> > +&can0 {
> > +       pinctrl-0 = <&pins_can0>;
> > +       pinctrl-names = "default";
> > +
> > +       status = "okay";
> > +};
> > +
> > +&can1 {
> > +       pinctrl-0 = <&pins_can1>;
> > +       pinctrl-names = "default";
> > +
> > +       status = "okay";
> > +};
> 
> According to the schematics and board documentation, only a single CAN

See above, RZ/N1-EB schematics has both connectors??

> connector is present, and the CAN interface to use must be selected
> using the CN10/CN11 jumpers.  Hence I think we need a #define and an
> #ifdef to configure this, or at least keep one interface disabled, and
> add a comment explaining why.

Our BSP release, by default enables both the CAN interfaces(CN10/CN11) jumpers.
I have a RZ/N1-EB carrier board and tested CAN loopback on these interfaces.

Cheers,
biju

RE: [PATCH v3 3/3] ARM: dts: r9a06g032-rzn1d400-db: Enable CAN{0,1}

[Biju Das]

Hi Geert,

> Subject: RE: [PATCH v3 3/3] ARM: dts: r9a06g032-rzn1d400-db: Enable
> CAN{0,1}
> 
> Hi Geert,
> 
> Thanks for the feedback.
> 
> > Subject: Re: [PATCH v3 3/3] ARM: dts: r9a06g032-rzn1d400-db: Enable
> > CAN{0,1}
> >
> > Hi Biju,
> >
> > On Tue, Aug 30, 2022 at 6:45 PM Biju Das <biju.das.jz@bp.renesas.com>
> > wrote:
> > > Enable CAN{0,1} on RZ/N1D-DB board.
> 
> My bad, it is RZ/N1D-DB CPU board fitted to RZ/N1-EB carrier board.
> Actually it enables CAN{0,1} on the carrier board.
> 
> > >
> > > Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com>
> > > ---
> > > v2->v3:
> > >  * No change
> >
> > Thanks for your patch!
> >
> > > --- a/arch/arm/boot/dts/r9a06g032-rzn1d400-db.dts
> > > +++ b/arch/arm/boot/dts/r9a06g032-rzn1d400-db.dts
> > > @@ -26,6 +26,20 @@ aliases {
> > >         };
> > >  };
> > >
> > > +&can0 {
> > > +       pinctrl-0 = <&pins_can0>;
> > > +       pinctrl-names = "default";
> > > +
> > > +       status = "okay";
> > > +};
> > > +
> > > +&can1 {
> > > +       pinctrl-0 = <&pins_can1>;
> > > +       pinctrl-names = "default";
> > > +
> > > +       status = "okay";
> > > +};
> >
> > According to the schematics and board documentation, only a single CAN
> 
> See above, RZ/N1-EB schematics has both connectors??
> 
> > connector is present, and the CAN interface to use must be selected
> > using the CN10/CN11 jumpers.  Hence I think we need a #define and an
> > #ifdef to configure this, or at least keep one interface disabled, and
> > add a comment explaining why.

OK, To avoid confusion, will guard enabling CAN1 with #define macro 
as cpu schematic doesn't mention about this.

Cheers,
Biju

> 
> Our BSP release, by default enables both the CAN interfaces(CN10/CN11)
> jumpers.
> I have a RZ/N1-EB carrier board and tested CAN loopback on these
> interfaces.
> 
> Cheers,
> biju
> 

Re: [PATCH v3 3/3] ARM: dts: r9a06g032-rzn1d400-db: Enable CAN{0,1}

[Geert Uytterhoeven]

Hi Biju,

On Thu, Sep 1, 2022 at 3:15 PM Biju Das <biju.das.jz@bp.renesas.com> wrote:
> > Subject: Re: [PATCH v3 3/3] ARM: dts: r9a06g032-rzn1d400-db: Enable
> > CAN{0,1}
>
> > On Tue, Aug 30, 2022 at 6:45 PM Biju Das <biju.das.jz@bp.renesas.com>
> > wrote:
> > > Enable CAN{0,1} on RZ/N1D-DB board.
>
> My bad, it is RZ/N1D-DB CPU board fitted to RZ/N1-EB carrier board.
> Actually it enables CAN{0,1} on the carrier board.
>
> > > Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com>

> > > --- a/arch/arm/boot/dts/r9a06g032-rzn1d400-db.dts
> > > +++ b/arch/arm/boot/dts/r9a06g032-rzn1d400-db.dts
> > > @@ -26,6 +26,20 @@ aliases {
> > >         };
> > >  };
> > >
> > > +&can0 {
> > > +       pinctrl-0 = <&pins_can0>;
> > > +       pinctrl-names = "default";
> > > +
> > > +       status = "okay";
> > > +};
> > > +
> > > +&can1 {
> > > +       pinctrl-0 = <&pins_can1>;
> > > +       pinctrl-names = "default";
> > > +
> > > +       status = "okay";
> > > +};
> >
> > According to the schematics and board documentation, only a single CAN
>
> See above, RZ/N1-EB schematics has both connectors??

AFAIU, CN10 and CN11 are not the real CAN connectors, they are headers
to add jumpers to select which CAN interface to route to the real CAN
connector J16.

> > connector is present, and the CAN interface to use must be selected
> > using the CN10/CN11 jumpers.  Hence I think we need a #define and an
> > #ifdef to configure this, or at least keep one interface disabled, and
> > add a comment explaining why.
>
> Our BSP release, by default enables both the CAN interfaces(CN10/CN11) jumpers.
> I have a RZ/N1-EB carrier board and tested CAN loopback on these interfaces.

Yeah, you can enable loopback by wiring CN10 and CN11 appropriately ;-)
But that's not intended for normal use.

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

Re: [PATCH v3 0/3] Add RZ/N1 CAN support

[Marc Kleine-Budde]

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

On 30.08.2022 17:45:15, Biju Das wrote:
> This patch series supports CAN{0,1} populated on RZ/N1D-DB board.
> 
> v2->v3:
>  * Documented power-domains support.
>  * Dropped clock-names property from CAN nodes.
>  * Added power-domains property to the CAN nodes.
> v1->v2:
>  * Added RZ/N1 specific compatible string.
>  * Added clock-names property.
> 
> This patch series depend upon [1]
> [1] https://lore.kernel.org/linux-renesas-soc/20220819084532.ywtziogd7ycuozxx@pengutronix.de/
> 
> Biju Das (3):
>   dt-bindings: can: nxp,sja1000: Document RZ/N1 power-domains support
>   ARM: dts: r9a06g032: Add CAN{0,1} nodes
>   ARM: dts: r9a06g032-rzn1d400-db: Enable CAN{0,1}

Who will take this series (once it's ready)?

regards,
Marc

-- 
Pengutronix e.K.                 | Marc Kleine-Budde           |
Embedded Linux                   | https://www.pengutronix.de  |
Vertretung West/Dortmund         | Phone: +49-231-2826-924     |
Amtsgericht Hildesheim, HRA 2686 | Fax:   +49-5121-206917-5555 |

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

RE: [PATCH v3 0/3] Add RZ/N1 CAN support

[Biju Das]

Hi Marc,

> Subject: Re: [PATCH v3 0/3] Add RZ/N1 CAN support
> 
> On 30.08.2022 17:45:15, Biju Das wrote:
> > This patch series supports CAN{0,1} populated on RZ/N1D-DB board.
> >
> > v2->v3:
> >  * Documented power-domains support.
> >  * Dropped clock-names property from CAN nodes.
> >  * Added power-domains property to the CAN nodes.
> > v1->v2:
> >  * Added RZ/N1 specific compatible string.
> >  * Added clock-names property.
> >
> > This patch series depend upon [1]
> > [1] https://lore.kernel.org/linux-renesas-
> soc/20220819084532.ywtziogd7ycuozxx@pengutronix.de/
> >
> > Biju Das (3):
> >   dt-bindings: can: nxp,sja1000: Document RZ/N1 power-domains support
> >   ARM: dts: r9a06g032: Add CAN{0,1} nodes
> >   ARM: dts: r9a06g032-rzn1d400-db: Enable CAN{0,1}
> 
> Who will take this series (once it's ready)?

I guess, normally bindings by respective maintainer(ie, by you) and 
Renesas SoC/board dtsi/dts by Geert. Already SoC dtsi is
queued for 6.1[1]. So I guess binding can be applied to respective subsystem
tree.

[1] https://patchwork.kernel.org/project/linux-renesas-soc/patch/20220830164518.1381632-3-biju.das.jz@bp.renesas.com/

Cheers,
Biju

Re: [PATCH v3 0/3] Add RZ/N1 CAN support

[Marc Kleine-Budde]

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

On 05.09.2022 16:13:09, Biju Das wrote:
> Hi Marc,
> 
> > Subject: Re: [PATCH v3 0/3] Add RZ/N1 CAN support
> > 
> > On 30.08.2022 17:45:15, Biju Das wrote:
> > > This patch series supports CAN{0,1} populated on RZ/N1D-DB board.
> > >
> > > v2->v3:
> > >  * Documented power-domains support.
> > >  * Dropped clock-names property from CAN nodes.
> > >  * Added power-domains property to the CAN nodes.
> > > v1->v2:
> > >  * Added RZ/N1 specific compatible string.
> > >  * Added clock-names property.
> > >
> > > This patch series depend upon [1]
> > > [1] https://lore.kernel.org/linux-renesas-
> > soc/20220819084532.ywtziogd7ycuozxx@pengutronix.de/
> > >
> > > Biju Das (3):
> > >   dt-bindings: can: nxp,sja1000: Document RZ/N1 power-domains support
> > >   ARM: dts: r9a06g032: Add CAN{0,1} nodes
> > >   ARM: dts: r9a06g032-rzn1d400-db: Enable CAN{0,1}
> > 
> > Who will take this series (once it's ready)?
> 
> I guess, normally bindings by respective maintainer(ie, by you) and 
> Renesas SoC/board dtsi/dts by Geert. Already SoC dtsi is
> queued for 6.1[1]. So I guess binding can be applied to respective subsystem
> tree.
> 
> [1] https://patchwork.kernel.org/project/linux-renesas-soc/patch/20220830164518.1381632-3-biju.das.jz@bp.renesas.com/

Ok, applied 1/3 to linux-can-next.

regards,
Marc

-- 
Pengutronix e.K.                 | Marc Kleine-Budde           |
Embedded Linux                   | https://www.pengutronix.de  |
Vertretung West/Dortmund         | Phone: +49-231-2826-924     |
Amtsgericht Hildesheim, HRA 2686 | Fax:   +49-5121-206917-5555 |

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