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

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 linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20201020211550.GA456889@lunn.ch>
Date:   Tue, 20 Oct 2020 23:15:50 +0200
From:   Andrew Lunn <andrew@...n.ch>
To:     Chris Packham <Chris.Packham@...iedtelesis.co.nz>
Cc:     Marek Behun <marek.behun@....cz>,
        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

Hi Chris

> So far I've not needed to use interrupts from the 6097. It's connected 
> on my hardware but never been tested.

The mv88e6xxx driver will also poll the interrupt bits, if the
interrupt is not wired to a GPIO.

> There are a couple of SERDES LinkInt bits in the Global2 interrupt
> source/mask register which look as though they should fire.

Sounds good. Maybe more 6352 code you can copy.

> > 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?

If you have all the code in place, what should happen is that the PCS
is powered up. It will try to establish a link with its peer. phylink
will also call serdes_pcs_an_restart() function to kick off auto-neg
on the PCS link. Once link is established, you should get an
interrupt. The interrupt handler then calls
dsa_port_phylink_mac_change() which tells phylink the PCS is now
up. It will use the serdes_pcs_get_state() call to find out what the
PCS pair have agreed on, and then configure the MAC with the same
information, forcing it.

Lets just hope you can do this, given the level of integration of the
PCS and MAC, in that there are no real PCS registers you can play
with.

	Andrew