Re: mv88e6240 configuration broken for B850v3

[Vladimir Oltean <olteanv@gmail.com>]

On Mon, Dec 06, 2021 at 08:18:30PM +0000, Russell King (Oracle) wrote:
> > If we're going to impersonate phylink we could at least provide the same
> > arguments as phylink will.
> 
> What is going on here in terms of impersonation is entirely reasonable.
> 
> The only things in this respect that phylink guarantees are:
> 
> 1) The MAC/PCS configuration will not be substantially reconfigured
>    unless a call to mac_link_down() was made if a call to mac_link_up()
>    was previously made.

The wording here is unclear. Did you mean "When the MAC/PCS configuration
is substantially reconfigured and the last call was a mac_link_up(), a
follow-up call to mac_link_down() will also be made"?

And what do you mean by "substantially reconfigured"?
phylink_major_config called from the paths that aren't phylink_mac_initial_config
(because that happens with no preceding call to either mac_link_down or
mac_link_up), right?

> 2) The arguments to mac_link_down() will be the same as the preceeding
>    mac_link_up() call - in other words, the "mode" and "interface".

Does this imply that "there will always be a preceding mac_link_up to
every mac_link_down call"? Because if it does imply that, DSA violates it.

> Phylink does *not* guarantee that a call to mac_link_up() or
> mac_config() will have the same "mode" as a preceeding call to
> mac_link_down(), in the same way that "interface" is not guaranteed.
> This has been true for as long as we've had SFPs that need to switch
> between MLO_AN_INBAND and MLO_AN_PHY - e.g. because the PHY doesn't
> supply in-band information.
> 
> So, this has uncovered a latent bug in the Marvell DSA code - and
> that is that mac_config() needs to take care of the forcing state
> after completing its configuration as I suggested in my previous
> reply.
> 
> There is also the question whether the automatic fetching of PHY
> status information by the hardware should be regarded as a form of
> in-band by phylink, even though it isn't true in-band - but from
> the software point of view, the PPU's automatic fetching is not
> materially different from what happens with SGMII.
> 
> -- 
> RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
> FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!