Re: [PATCH v3 1/3] net: dsa: mv88e6xxx: Don't force link when using in-band-status

[Chris Packham]

On 21/10/20 3:58 am, Andrew Lunn wrote:
>>> It's still there. The speed/duplex etc are read from the serdes PHY
>>> via mv88e6390_serdes_pcs_get_state(). When the link comes up, we
>>> pass the negotiated link parameters read from there to the link_up()
>>> functions. For ports where mv88e6xxx_port_ppu_updates() returns false
>>> (no external PHY) we update the port's speed and duplex setting and
>>> (currently, before this patch) force the link up.
>>>
>>> That was the behaviour before I converted the code, the one that you
>>> referred to. I had assumed the code was correct, and _none_ of the
>>> speed, duplex, nor link state was propagated from the serdes PCS to
>>> the port on the 88E6390 - hence why the code you refer to existed.
>>>
> Chris
>
> Do you get an interrupt when the link goes up? Since there are no
> SERDES registers, there is no specific SERDES interrupt. But maybe the
> PHY interrupt in global 2 fires?
So far I've not needed to use interrupts from the 6097. It's connected 
on my hardware but never been tested. There are a couple of SERDES 
LinkInt bits in the Global2 interrupt source/mask register which look as 
though they should fire.
> If you can use that, you can then be
> more in line with the other implementations and not need this change.
My particular problem was actually on the other end of the link (which 
is a 98dx160 that doesn't currently have a dsa driver). When the link 
was forced on the 6097 end it would only link up if the 6097 came up 
after the dx160. Are you saying there is a way of avoiding the call to 
mv88e6xxx_mac_link_up() if I have interrupts for the serdes ports?