lkml.org 
[lkml]   [2020]   [Oct]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: [PATCH v3 1/3] net: dsa: mv88e6xxx: Don't force link when using in-band-status
Date

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?
\
 
 \ /
  Last update: 2020-10-20 23:04    [W:0.077 / U:2.920 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site