linux-kernel - Re: [PATCH] riscv: dts: sophgo: Add ethernet configuration for cv18xx

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <5b08e092-c302-43a9-a04d-3566bec96e94@lunn.ch>
Date: Fri, 1 Nov 2024 13:40:00 +0100
From: Andrew Lunn <andrew@...n.ch>
To: Inochi Amaoto <inochiama@...il.com>
Cc: Chen Wang <unicorn_wang@...look.com>, Rob Herring <robh@...nel.org>,
	Krzysztof Kozlowski <krzk+dt@...nel.org>,
	Conor Dooley <conor+dt@...nel.org>,
	Inochi Amaoto <inochiama@...look.com>,
	Paul Walmsley <paul.walmsley@...ive.com>,
	Palmer Dabbelt <palmer@...belt.com>,
	Albert Ou <aou@...s.berkeley.edu>,
	Richard Cochran <richardcochran@...il.com>,
	Jisheng Zhang <jszhang@...nel.org>,
	Thomas Bonnefille <thomas.bonnefille@...tlin.com>,
	Liu Gui <kenneth.liu@...hgo.com>, Yixun Lan <dlan@...too.org>,
	Longbin Li <looong.bin@...il.com>, devicetree@...r.kernel.org,
	linux-riscv@...ts.infradead.org, linux-kernel@...r.kernel.org,
	netdev@...r.kernel.org
Subject: Re: [PATCH] riscv: dts: sophgo: Add ethernet configuration for cv18xx

> > > > > > +			mdio {
> > > > > > +				compatible = "snps,dwmac-mdio";
> > > > > > +				#address-cells = <1>;
> > > > > > +				#size-cells = <0>;
> > > > > > +
> > > > > > +				phy0: phy@0 {
> > > > > > +					compatible = "ethernet-phy-ieee802.3-c22";
> > > > > > +					reg = <0>;
> > > > > > +				};
> > > > > > +			};
> > > > > 
> > > > > It is not clear to me what cv18xx.dtsi represents, 
> > > > 
> > > > This is a include file to define common ip for the whole
> > > > cv18xx series SoCs (cv1800b, cv1812h, sg2000, sg2000).
> > > > 
> > > > > and where the PHY node should be, here, or in a .dts file. 
> > > > > Is this a SOM, and the PHY is on the SOM? 
> > > > 
> > > > The phy is on the SoC, it is embedded, and no external phy
> > > > is supported. So I think the phy node should stay here, not 
> > > > in the dts file.
> > > 
> > > There is a mistake, Some package supports external rmii/mii
> > > phy. So I will move this phy definition to board specific.
> > 
> > When there is an external PHY, does the internal PHY still exists? If
> > it does, it should be listed, even if it is not used.
> > 
> > Do the internal and external PHY share the same MDIO bus? 
> 
> They share the same MDIO bus and phy id setting.

What do you mean by phy ID?

> When an external phy
> is select, the internal one is not initialized and can not be accessed
> by the SoC.
> 
> > I've seen some SoCs with complex MDIO muxes for internal vs external
> > PHYs.
> > 
> > 	Andrew
> 
> There is a switch register on the SoC to decide which phy/mode is used. 
> By defaut is internal one with rmii mode. I think a driver is needed to
> handle this properly.

This sounds like a complex MDIO mux. You should think about this now,
because others have left this same problem too late and ended up with
a complex design in order to keep backwards compatibility with old DT
blobs which don't actually describe the real hardware.

	Andrew