linux-kernel - Re: [PATCH v2 2/2] arm64: dts: renesas: r9a09g057h44-rzv2h-evk: Enable GBETH

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <CA+V-a8vrF178XqqtECqNrXJRSWD8MGmBZvCbutsi2uggJWDjWQ@mail.gmail.com>
Date: Mon, 12 May 2025 20:49:04 +0100
From: "Lad, Prabhakar" <prabhakar.csengg@...il.com>
To: Geert Uytterhoeven <geert@...ux-m68k.org>
Cc: Magnus Damm <magnus.damm@...il.com>, Rob Herring <robh@...nel.org>, 
	Krzysztof Kozlowski <krzk+dt@...nel.org>, Conor Dooley <conor+dt@...nel.org>, 
	linux-renesas-soc@...r.kernel.org, devicetree@...r.kernel.org, 
	linux-kernel@...r.kernel.org, Biju Das <biju.das.jz@...renesas.com>, 
	Fabrizio Castro <fabrizio.castro.jz@...esas.com>, 
	Lad Prabhakar <prabhakar.mahadev-lad.rj@...renesas.com>
Subject: Re: [PATCH v2 2/2] arm64: dts: renesas: r9a09g057h44-rzv2h-evk:
 Enable GBETH

Hi Geert,

Thank you for the review.

On Mon, May 12, 2025 at 8:05 PM Geert Uytterhoeven <geert@...ux-m68k.org> wrote:
>
> Hi Prabhakar,
>
> On Fri, 9 May 2025 at 17:36, Prabhakar <prabhakar.csengg@...il.com> wrote:
> > From: Lad Prabhakar <prabhakar.mahadev-lad.rj@...renesas.com>
> >
> > Enable the GBETH nodes on the RZ/V2H Evaluation Kit.
> >
> > Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@...renesas.com>
>
> Thanks for your patch!
>
> LGTM, so
> Reviewed-by: Geert Uytterhoeven <geert+renesas@...der.be>
>
> > --- a/arch/arm64/boot/dts/renesas/r9a09g057h44-rzv2h-evk.dts
> > +++ b/arch/arm64/boot/dts/renesas/r9a09g057h44-rzv2h-evk.dts
> > @@ -78,6 +80,68 @@ &audio_extal_clk {
> >         clock-frequency = <22579200>;
> >  };
> >
> > +&eth0 {
> > +       pinctrl-0 = <&eth0_pins>;
> > +       pinctrl-names = "default";
> > +       phy-handle = <&phy0>;
> > +       phy-mode = "rgmii-id";
> > +       status = "okay";
> > +
> > +       mdio {
> > +               #address-cells = <1>;
> > +               #size-cells = <0>;
> > +               compatible = "snps,dwmac-mdio";
>
> I am just wondering if the above parts of the mdio subnodes should be
> moved to the SoC-specific .dtsi instead, as it is part of the SoC and
> fairly static?
>
Agreed, I will move this to SoC DTSI.

> Both approaches seem to be popular: e.g. rk3568.dtsi[1] has the mdio
> subnode in the SoC part, and rk3568-nanopi-r5s.dts[2] extends the
> subnode, while rk3399-orangepi.dts[3] has the full subnode in the
> board part.
>
> [1] arch/arm64/boot/dts/rockchip/rk3568.dtsi
> [2] arch/arm64/boot/dts/rockchip/rk3568-nanopi-r5s.dts
> [3] arch/arm64/boot/dts/rockchip/rk3399-orangepi.dts
>

[3] was added earlier, [1]/[2] seem more recent. So let's go with the
mdio node in SoC DTSI.

Cheers,
Prabhakar