Re: [PATCH net-next 4/4] net: dsa: remove phylink_validate() method

[Vladimir Oltean <vladimir.oltean@nxp.com>]

On Tue, Nov 01, 2022 at 12:01:32PM +0000, Russell King (Oracle) wrote:
> On Tue, Nov 01, 2022 at 01:48:06PM +0200, Vladimir Oltean wrote:
> > Not all DSA drivers provide config->mac_capabilities, for example
> > mv88e6060, lan9303 and vsc73xx don't. However, there have been users of
> > those drivers on recent kernels and no one reported that they fail to
> > establish a link, so I'm guessing that they work (somehow). But I must
> > admit I don't understand why phylink_generic_validate() works when
> > mac_capabilities=0. Anyway, these drivers did not provide a
> > phylink_validate() method before and do not provide one now, so nothing
> > changes for them.
> 
> There is a specific exception:
> 
> When config->mac_capabilities is zero, and there is no phylink_validate()
> function, dsa_port_phylink_validate() becomes a no-op, and the no-op
> case basically means "everything is allowed", which is how things worked
> before the generic validation was added, as you will see from commit
> 5938bce4b6e2 ("net: dsa: support use of phylink_generic_validate()").
> 
> Changing this as you propose below will likely break these drivers.
> 
> A safer change would be to elimate ds->ops->phylink_validate, leaving
> the call to phylink_generic_validate() conditional on mac_capabilities
> having been filled in - which will save breaking these older drivers.

Yes, this is correct, thanks; our emails crossed.

Between keeping a no-op phylink_validate() for these drivers and filling
in mac_capabilities for them, to remove this extra code path in DSA,
what would be preferred?

The 3 drivers I mentioned could all get a blanket MAC_10 | MAC_100 |
MAC1000FD | MAC_ASYM_PAUSE | MAC_SYM_PAUSE to keep advertising what they
did, even if this may or may not be 100% correct (lan9303 and mv88e6060
are not gigabit, and I don't know if they do flow control properly), but
these issues are not new.