> On the other hand I found arm64/boot/dts/marvell/cn9130-crb.dtsi, where
> the switch, a "marvell,mv88e6190"-compatible (can't determine going just
> by that what it actually is) has this:
>
> port@a {
> reg = <10>;
> label = "cpu";
> ethernet = <&cp0_eth0>;
> };
Both CPU and DSA ports default to their maximum speed, if nothing else
is specified. If this is a 6393X, port 10 can do 10Gbps, and that is
how the port will be configured by the driver. It is undefined how it
actually implement this maximum speed, if there are multiple choices,
if in band is enabled or not etc. This is historical, the first
mv88e6xxx devices had a mixture of Fast and 1G ethernet interfaces,
and it was simply to choosing between MII and GMII. The platform data
at that time had no way to express link information, and this simple
default mechanism was enough to get boards of the time working.
> To illustrate how odd the situation is, I am able to follow the phandle
> to the CPU port and find a comment that it's a 88E6393X, and that the
> CPU port uses managed = "in-band-status":
>
> &cp0_eth0 {
> /* This port is connected to 88E6393X switch */
> status = "okay";
> phy-mode = "10gbase-r";
> managed = "in-band-status";
> phys = <&cp0_comphy4 0>;
> };
>
> Open question: is it sane to even do what we're trying here, to create a
> fixed-link for port@a (which makes the phylink instance use MLO_AN_FIXED)
> when &cp0_eth0 uses MLO_AN_INBAND? My simple mind thinks that if all
> involved drivers were to behave correctly
Define 'correctly', given that some of these drivers and devices have
been around much longer than device tree, etc.
Andrew
