Re: [RFC v1 net-next 7/7] net: dsa: ocelot_ext: add support for external phys

From: Colin Foster
Date: Thu Feb 16 2023 - 20:31:34 EST


On Thu, Feb 16, 2023 at 11:17:48AM +0000, Russell King (Oracle) wrote:
> Hi Colin,
>
> On Wed, Feb 15, 2023 at 11:53:21PM -0800, Colin Foster wrote:
> > +static const struct phylink_mac_ops ocelot_ext_phylink_ops = {
> > + .validate = phylink_generic_validate,
>
> There is no need to set this anymore.

I'll remove. Thanks.

> > +static int ocelot_ext_pcs_config(struct phylink_pcs *pcs, unsigned int mode,
> > + phy_interface_t interface,
> > + const unsigned long *advertising,
> > + bool permit_pause_to_mac)
> > +{
> > + struct ocelot_ext_port_priv *port_priv =
> > + phylink_pcs_to_ocelot_port(pcs);
> > +
> > + switch (interface) {
> > + case PHY_INTERFACE_MODE_QSGMII:
> > + ocelot_ext_phylink_mac_config(&port_priv->phylink_config, mode,
> > + NULL);
>
> Why are you calling a "mac" operation from a "pcs" operation? If this
> PCS is attached to the same phylink instance as the MAC, you'll get
> the .mac_config method called along with the .pcs_config, so calling
> one from the other really isn't necessary.

Per the other email, it was my misunderstanding - probably from the
unnecessary phylink_create(). V2 will be cleaned up.

...

> > +
> > + phylink = phylink_create(&ocelot_ext_port_priv->phylink_config,
> > + of_fwnode_handle(portnp),
> > + phy_mode, &ocelot_ext_phylink_ops);
>
> I'm confused. DSA already sets up a phylink instance per port, so why
> do you need another one?

Also in the other email, it is definitely my confusion. I'll get things
straighened out for V2, as these patches seem more complicated than they
need to be.


Thanks again!

>
> Thanks.
>
> --
> RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
> FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!