On Wed, Mar 22, 2023 at 09:17:02PM +0100, Andrew Lunn wrote:
> On Wed, Mar 22, 2023 at 08:13:51PM +0000, Russell King (Oracle) wrote:
> > On Wed, Mar 22, 2023 at 07:57:19PM +0100, Andrew Lunn wrote:
> > > > +static struct fwnode_handle *mv88e6xxx_port_get_fwnode(struct dsa_switch *ds,
> > > > + int port,
> > > > + struct fwnode_handle *h)
> > > > +{
> > > > + struct mv88e6xxx_chip *chip = ds->priv;
> > > > + struct device_node *np, *phy_node;
> > > > + int speed, duplex, err;
> > > > + phy_interface_t mode;
> > > > + struct dsa_port *dp;
> > > > + unsigned long caps;
> > > > +
> > > > + dp = dsa_to_port(ds, port);
> > > > + if (dsa_port_is_user(dp))
> > > > + return h;
> > > > +
> > > > + /* No DT? Eh? */
> > > > + np = to_of_node(h);
> > > > + if (!np)
> > > > + return h;
> > >
> > > I've not looked at the big picture yet, but you can have a simple
> > > switch setup without DT. I have a couple of amd64 boards which use
> > > platform data. The user ports all have internal PHYs, and the CPU port
> > > defaults to 1G, it might even be strapped that way.
> >
> > Are you suggesting that we should generate some swnode description of
> > the max interface mode and speed if we are missing a DT node?
> >
> > I'm not seeing any port specific data in the mv88e6xxx platform data.
>
> No, i'm just pointing out that not have DT is not an error, and can
> happen. I just wanted to make sure you are not assuming there is
> always DT.
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.
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!
