Re: mv88e6240 configuration broken for B850v3

[Vladimir Oltean <olteanv@gmail.com>]

On Mon, Dec 06, 2021 at 08:51:09PM +0000, Russell King (Oracle) wrote:
> On Mon, Dec 06, 2021 at 10:23:08PM +0200, Vladimir Oltean wrote:
> > On Mon, Dec 06, 2021 at 08:07:45PM +0000, Russell King (Oracle) wrote:
> > > My conclusion from having read this thread is the CPU port is using PPU
> > > polling, meaning that in mac_link_up():
> > > 
> > >         if ((!mv88e6xxx_phy_is_internal(ds, port) &&
> > >              !mv88e6xxx_port_ppu_updates(chip, port)) ||
> > >             mode == MLO_AN_FIXED) {
> > > 
> > > is false - because mv88e6xxx_port_ppu_updates() returns true, and
> > > consequently we never undo this force-down.
> > 
> > We know that
> > 1. A == mv88e6xxx_phy_is_internal(ds, port), B == mv88e6xxx_port_ppu_updates(chip, port), C == mode == MLO_AN_FIXED
> > 2. (!A && !B) || C == false. This is due to the effect we observe: link is not forced up
> > 2. C == false. This is due to the device tree.
> > 3. !A && !B == false. This is due to statement (2), plus the rule that if X || Y == false and Y == false, then X must also be false.
> > 4. We know that A is true, again due to device tree: port 4 < .num_internal_phys for MV88E6240 which is 5.
> > 5. !A is false, due to 4.
> > 
> > So we have:
> > 
> > false && !B == false.
> > 
> > Therefore "!B" is "don't care". In other words we don't know whether
> > mv88e6xxx_port_ppu_updates() is true or not.
> 
> With a bit of knowledge of how Marvell DSA switches work...
> 
> The "ppu" is the PHY polling unit. When the switch comes out of reset,
> the PPU probes the MDIO bus, and sets the bit in the port status
> register depending on whether it detects a PHY at the port address by
> way of the PHY ID values. This bit is used to enable polling of the
> PHY and is what mv88e6xxx_port_ppu_updates() reports. This bit will be
> set for all internal PHYs unless we explicitly turn it off (we don't.)
> Therefore, this is a reasonable assumption to make.
> 
> So, given that mv88e6xxx_port_ppu_updates() is most likely true as
> I stated, it is also true that mv88e6xxx_phy_is_internal() is
> "don't care".

And the reason why you bring the PPU into the discussion is because?
If the issue manifests itself with or without it, and you come up with a
proposal to set LINK_UNFORCED in mv88e6xxx_mac_config if the PPU is
used, doesn't that, logically speaking, still leave the issue unsolved
if the PPU is _not_ used for whatever reason?
The bug has nothing to do with the PPU. It can be solved by checking for
PPU in-band status as you say. Maybe. But I've got no idea why we don't
address the elephant in the room, which is in dsa_port_link_register_of()?