linux-kernel - 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]

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?