[PATCH] riscv: dts: sophgo: Add ethernet configuration for cv18xx
Inochi Amaoto
inochiama at gmail.com
Fri Nov 1 17:49:26 PDT 2024
On Fri, Nov 01, 2024 at 01:40:00PM +0100, Andrew Lunn wrote:
> > > > > > > + mdio {
> > > > > > > + compatible = "snps,dwmac-mdio";
> > > > > > > + #address-cells = <1>;
> > > > > > > + #size-cells = <0>;
> > > > > > > +
> > > > > > > + phy0: phy at 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?
>
It is just part of the MDIO mux. Just ignore it. It is just
used to show only one phy can be used at the same time.
> > 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
Thanks, I wiil design a driver for it to handle this mux.
Regards,
Inochi
More information about the linux-riscv
mailing list