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

["Russell King (Oracle)" <linux@armlinux.org.uk>]

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:

static void dsa_port_phylink_validate(struct phylink_config *config,
                                      unsigned long *supported,
                                      struct phylink_link_state *state)
{
        struct dsa_port *dp = container_of(config, struct dsa_port, pl_config);
        struct dsa_switch *ds = dp->ds;

        if (!ds->ops->phylink_validate) {
                if (config->mac_capabilities)
                        phylink_generic_validate(config, supported, state);
                return;

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.

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