> Otherwise the MDIO bus and its phy should be a
> child of the nic/mac using it, with standardized behaviors/etc left up to
> the OSPM when it comes to MDIO bus enumeration/etc.
Hi Jeremy
Could you be a bit more specific here please.
DT allows
macb0: ethernet@fffc4000 {
compatible = "cdns,at32ap7000-macb";
reg = <0xfffc4000 0x4000>;
interrupts = <21>;
phy-mode = "rmii";
local-mac-address = [3a 0e 03 04 05 06];
clock-names = "pclk", "hclk", "tx_clk";
clocks = <&clkc 30>, <&clkc 30>, <&clkc 13>;
ethernet-phy@1 {
reg = <0x1>;
reset-gpios = <&pioE 6 1>;
};
};
So the PHY is a direct child of the MAC. The MDIO bus is not modelled
at all. Although this is allowed, it is deprecated, because it results
in problems with advanced systems which have multiple different
children, and the need to differentiate them. So drivers are slowly
migrating to always modelling the MDIO bus. In that case, the
phy-handle is always used to point to the PHY:
eth0: ethernet@522d0000 {
compatible = "socionext,synquacer-netsec";
reg = <0 0x522d0000 0x0 0x10000>, <0 0x10000000 0x0 0x10000>;
interrupts = <GIC_SPI 176 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&clk_netsec>;
clock-names = "phy_ref_clk";
phy-mode = "rgmii";
max-speed = <1000>;
max-frame-size = <9000>;
phy-handle = <&phy1>;
mdio {
#address-cells = <1>;
#size-cells = <0>;
phy1: ethernet-phy@1 {
compatible = "ethernet-phy-ieee802.3-c22";
reg = <1>;
};
};
"mdio-handle" is just half of phy-handle.
What you seem to be say is that although we have defined a generic
solution for ACPI which should work in all cases, it is suggested to
not use it? What exactly are you suggesting in its place?
Andrew
