On Wed, Mar 22, 2023 at 10:40:26PM +0100, Andrew Lunn wrote:
> > What I'm trying to find out is what you think the behaviour should be
> > in this case. Are you suggesting we should fall back to what we do now
> > which is let the driver do it internally without phylink.
> >
> > The problem is that if we don't go down the phylink route for everything
> > then we /can't/ convert mv88e6xxx to phylink_pcs, because the "serdes"
> > stuff will be gone, and the absence of phylink will mean those won't be
> > called e.g. to power up the serdes.
>
> I'm pretty sure non-DT systems have never used SERDES. They are using
> a back to back PHY, or maybe RGMII. So long as this keeps working, we
> can convert to phylink.
>
> And i have such a amd64 system, using back to back PHYs so i can test
> it does not regress.
Reading the code, I don't think we have any issue with the DSA and CPU
ports, as these check whether dp->dn is not NULL before calling
dsa_shared_port_link_register_of() and the validator. This means these
paths will only be used for setups that have DT.
For the user ports, we can end up calling dsa_port_phylink_create()
with a NULL dp->dn, and must not fail.
So, given that this is only supposed to be used for mv88e6xxx because
of it's legacy, maybe the check in dsa_port_phylink_create() should
be:
fwnode = of_fwnode_handle(dp->dn);
if (fwnode && ds->ops->port_get_fwnode) {
In other words, we only allow the replacement of the firmware
description if one already existed.
Alternatively, we could use:
if (!dsa_port_is_user(dp) && ds->ops->port_get_fwnode) {
since mv88e6xxx today only does this "max speed" thing for CPU and
DSA ports, and thus we only need to replace the firmware description
for these ports - and we can document that port_get_fwnode is only
for CPU and DSA ports.
Hmm?
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!
