lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Tue, 20 Oct 2020 21:04:07 +0000 From: Chris Packham <Chris.Packham@...iedtelesis.co.nz> To: Andrew Lunn <andrew@...n.ch>, Marek Behun <marek.behun@....cz> CC: Russell King - ARM Linux admin <linux@...linux.org.uk>, "vivien.didelot@...il.com" <vivien.didelot@...il.com>, "f.fainelli@...il.com" <f.fainelli@...il.com>, "olteanv@...il.com" <olteanv@...il.com>, "davem@...emloft.net" <davem@...emloft.net>, "kuba@...nel.org" <kuba@...nel.org>, "netdev@...r.kernel.org" <netdev@...r.kernel.org>, "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org> Subject: Re: [PATCH v3 1/3] net: dsa: mv88e6xxx: Don't force link when using in-band-status 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?
Powered by blists - more mailing lists