netdev - Re: [PATCH RFC net-next 5/6] net: dsa: always use phylink for CPU and DSA ports

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] [day] [month] [year] [list]

Message-ID: <YsCqFM8qM1h1MKu/@shell.armlinux.org.uk>
Date:   Sat, 2 Jul 2022 21:27:00 +0100
From:   "Russell King (Oracle)" <linux@...linux.org.uk>
To:     Marek Behún <kabel@...nel.org>
Cc:     Andrew Lunn <andrew@...n.ch>,
        Heiner Kallweit <hkallweit1@...il.com>,
        Alexandre Belloni <alexandre.belloni@...tlin.com>,
        Alvin __ipraga <alsi@...g-olufsen.dk>,
        Claudiu Manoil <claudiu.manoil@....com>,
        "David S. Miller" <davem@...emloft.net>,
        DENG Qingfang <dqfext@...il.com>,
        Eric Dumazet <edumazet@...gle.com>,
        Florian Fainelli <f.fainelli@...il.com>,
        George McCollister <george.mccollister@...il.com>,
        Hauke Mehrtens <hauke@...ke-m.de>,
        Jakub Kicinski <kuba@...nel.org>,
        Kurt Kanzenbach <kurt@...utronix.de>,
        Landen Chao <Landen.Chao@...iatek.com>,
        Linus Walleij <linus.walleij@...aro.org>,
        linux-arm-kernel@...ts.infradead.org,
        linux-mediatek@...ts.infradead.org,
        Matthias Brugger <matthias.bgg@...il.com>,
        netdev@...r.kernel.org, Paolo Abeni <pabeni@...hat.com>,
        Sean Wang <sean.wang@...iatek.com>,
        UNGLinuxDriver@...rochip.com,
        Vivien Didelot <vivien.didelot@...il.com>,
        Vladimir Oltean <olteanv@...il.com>,
        Woojung Huh <woojung.huh@...rochip.com>
Subject: Re: [PATCH RFC net-next 5/6] net: dsa: always use phylink for CPU
 and DSA ports

On Fri, Jul 01, 2022 at 09:34:35PM +0200, Marek Behún wrote:
> On Wed, 29 Jun 2022 13:51:43 +0100
> "Russell King (Oracle)" <rmk+kernel@...linux.org.uk> wrote:
> 
> > Currently, we only use phylink for CPU and DSA ports if there is a
> > fixed-link specification, or a PHY specified. The reason for this
> > behaviour is that when neither is specified, there was no way for
> > phylink to know the link parameters.
> > 
> > Now that we have phylink_set_max_link_speed() (which has become
> > possible through the addition of mac_capabilities) we now have the
> > ability to know the maximum link speed for a specific link, and can
> > now use phylink for this case as well.
> > 
> > However, we need DSA drivers to report the interface mode being used
> > on these ports so that we can select a maximum speed appropriate for
> > the interface mode that hardware may have configured for the port.
> > 
> > This is especially important with the conversion of DSA drivers to
> > phylink_pcs, as the PCS code only gets called if we are using
> > phylink for the port.
> > 
> > Signed-off-by: Russell King (Oracle) <rmk+kernel@...linux.org.uk>
> 
> Reviewed-by: Marek Behún <kabel@...nel.org>
> 
> So this is the one that may break other drivers?

It's the one that I'm most concerned about breakage happening, because
the other drivers won't be setting the default interface for the port,
which means if they're taking advantage of this "defaulting" feature,
this patch will break them.

The original code just did nothing when this "defaulting" feature was
used - it didn't call the DSA phylink_mac_link_down() op, and didn't
register with phylink. The phylink_mac_link_down() there was to ensure
that the ports are in a link-down state prior to setting up phylink,
because that's what phylink expects.

The problem comes is that once we've called phylink_mac_link_down(),
there isn't a way to back out of that without knowing the interface
mode, speed, duplex etc - which is the problem with this defaulting
feature, none of that is specified in DT, it can only come from the
drivers.

Note that the mv88e6xxx series I posted earlier depends on getting this
problem sorted - if we don't, I can't send the mv88e6xxx pcs conversion
because mv88e6xxx boards that _do_ make use of this defaulting feature
will break (and there are a number that do make use of it.)

If I send this RFC series (minus the top patch) then all the drivers
that make use of this defualting feature that aren't mv88e6xxx will
probably break - but I've no idea which make use of this feature
because it's not documented. It's not really documented in the DT
binding either, it's just something that Andrew "knows about",
mv88e6xxx makes use of, and Andrew has suggested to some other DSA
driver authors.

This absolutely needs Andrew's involvement.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!