quoted

quoted

quoted

quoted

quoted

+			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).

quoted

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.

quoted

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