Re: [PATCH RFC net-next 5/6] net: dsa: always use phylink for CPU and DSA ports

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

On Fri, Jul 01, 2022 at 09:34:35PM +0200, Marek Behún wrote:
> On Wed, 29 Jun 2022 13:51:43 +0100
> "Russell King (Oracle)" <rmk+kernel@armlinux.org.uk> wrote:
> 
> > Currently, we only use phylink for CPU and DSA ports if there is a
> > fixed-link specification, or a PHY specified. The reason for this
> > behaviour is that when neither is specified, there was no way for
> > phylink to know the link parameters.
> > 
> > Now that we have phylink_set_max_link_speed() (which has become
> > possible through the addition of mac_capabilities) we now have the
> > ability to know the maximum link speed for a specific link, and can
> > now use phylink for this case as well.
> > 
> > However, we need DSA drivers to report the interface mode being used
> > on these ports so that we can select a maximum speed appropriate for
> > the interface mode that hardware may have configured for the port.
> > 
> > This is especially important with the conversion of DSA drivers to
> > phylink_pcs, as the PCS code only gets called if we are using
> > phylink for the port.
> > 
> > Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
> 
> Reviewed-by: Marek Behún <kabel@kernel.org>
> 
> So this is the one that may break other drivers?

It's the one that I'm most concerned about breakage happening, because
the other drivers won't be setting the default interface for the port,
which means if they're taking advantage of this "defaulting" feature,
this patch will break them.

The original code just did nothing when this "defaulting" feature was
used - it didn't call the DSA phylink_mac_link_down() op, and didn't
register with phylink. The phylink_mac_link_down() there was to ensure
that the ports are in a link-down state prior to setting up phylink,
because that's what phylink expects.

The problem comes is that once we've called phylink_mac_link_down(),
there isn't a way to back out of that without knowing the interface
mode, speed, duplex etc - which is the problem with this defaulting
feature, none of that is specified in DT, it can only come from the
drivers.

Note that the mv88e6xxx series I posted earlier depends on getting this
problem sorted - if we don't, I can't send the mv88e6xxx pcs conversion
because mv88e6xxx boards that _do_ make use of this defaulting feature
will break (and there are a number that do make use of it.)

If I send this RFC series (minus the top patch) then all the drivers
that make use of this defualting feature that aren't mv88e6xxx will
probably break - but I've no idea which make use of this feature
because it's not documented. It's not really documented in the DT
binding either, it's just something that Andrew "knows about",
mv88e6xxx makes use of, and Andrew has suggested to some other DSA
driver authors.

This absolutely needs Andrew's involvement.

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