netdev - Re: mv88e6240 configuration broken for B850v3

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:   Mon, 6 Dec 2021 22:29:02 +0200
From:   Vladimir Oltean <olteanv@...il.com>
To:     "Russell King (Oracle)" <linux@...linux.org.uk>
Cc:     Andrew Lunn <andrew@...n.ch>,
        Martyn Welch <martyn.welch@...labora.com>,
        Vivien Didelot <vivien.didelot@...il.com>,
        Florian Fainelli <f.fainelli@...il.com>,
        netdev@...r.kernel.org, kernel@...labora.com
Subject: Re: mv88e6240 configuration broken for B850v3

On Mon, Dec 06, 2021 at 08:18:30PM +0000, Russell King (Oracle) wrote:
> Phylink does *not* guarantee that a call to mac_link_up() or
> mac_config() will have the same "mode" as a preceeding call to
> mac_link_down(), in the same way that "interface" is not guaranteed.
> This has been true for as long as we've had SFPs that need to switch
> between MLO_AN_INBAND and MLO_AN_PHY - e.g. because the PHY doesn't
> supply in-band information.
> 
> So, this has uncovered a latent bug in the Marvell DSA code - and
> that is that mac_config() needs to take care of the forcing state
> after completing its configuration as I suggested in my previous
> reply.

I can understand between MLO_AN_INBAND and MLO_AN_PHY, but isn't it
reasonable that a "fixed" link is "fixed" and doesn't change?
After all, it's in the name. The mv88e6xxx code doesn't appear
necessarily problematic. This issue could crop up again and again with
other drivers.