Messages in this thread | | | From | Chris Packham <> | Subject | Re: [PATCH v3 1/3] net: dsa: mv88e6xxx: Don't force link when using in-band-status | Date | Tue, 20 Oct 2020 21:04:07 +0000 |
| |
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?
| |