netdev - Re: [PATCH net-next 4/4] net: dsa: remove phylink

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: <Y2E+dvH+zk1/QPpB@shell.armlinux.org.uk>
Date:   Tue, 1 Nov 2022 15:42:46 +0000
From:   "Russell King (Oracle)" <linux@...linux.org.uk>
To:     Vladimir Oltean <vladimir.oltean@....com>
Cc:     "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        Claudiu Manoil <claudiu.manoil@....com>,
        Alexandre Belloni <alexandre.belloni@...tlin.com>,
        "UNGLinuxDriver@...rochip.com" <UNGLinuxDriver@...rochip.com>,
        Heiner Kallweit <hkallweit1@...il.com>,
        Sean Anderson <sean.anderson@...o.com>,
        Colin Foster <colin.foster@...advantage.com>,
        Andrew Lunn <andrew@...n.ch>,
        Vivien Didelot <vivien.didelot@...il.com>,
        Florian Fainelli <f.fainelli@...il.com>,
        "David S. Miller" <davem@...emloft.net>,
        Eric Dumazet <edumazet@...gle.com>,
        Jakub Kicinski <kuba@...nel.org>,
        Paolo Abeni <pabeni@...hat.com>
Subject: Re: [PATCH net-next 4/4] net: dsa: remove phylink_validate() method

On Tue, Nov 01, 2022 at 12:40:36PM +0000, Vladimir Oltean wrote:
> On Tue, Nov 01, 2022 at 12:01:32PM +0000, Russell King (Oracle) wrote:
> > On Tue, Nov 01, 2022 at 01:48:06PM +0200, Vladimir Oltean wrote:
> > > Not all DSA drivers provide config->mac_capabilities, for example
> > > mv88e6060, lan9303 and vsc73xx don't. However, there have been users of
> > > those drivers on recent kernels and no one reported that they fail to
> > > establish a link, so I'm guessing that they work (somehow). But I must
> > > admit I don't understand why phylink_generic_validate() works when
> > > mac_capabilities=0. Anyway, these drivers did not provide a
> > > phylink_validate() method before and do not provide one now, so nothing
> > > changes for them.
> > 
> > There is a specific exception:
> > 
> > When config->mac_capabilities is zero, and there is no phylink_validate()
> > function, dsa_port_phylink_validate() becomes a no-op, and the no-op
> > case basically means "everything is allowed", which is how things worked
> > before the generic validation was added, as you will see from commit
> > 5938bce4b6e2 ("net: dsa: support use of phylink_generic_validate()").
> > 
> > Changing this as you propose below will likely break these drivers.
> > 
> > A safer change would be to elimate ds->ops->phylink_validate, leaving
> > the call to phylink_generic_validate() conditional on mac_capabilities
> > having been filled in - which will save breaking these older drivers.
> 
> Yes, this is correct, thanks; our emails crossed.
> 
> Between keeping a no-op phylink_validate() for these drivers and filling
> in mac_capabilities for them, to remove this extra code path in DSA,
> what would be preferred?

My stance has always been - if we don't know the answer to a question
that affects a code path in a way we want to, we can't modify that code
path. That said:

> The 3 drivers I mentioned could all get a blanket MAC_10 | MAC_100 |
> MAC1000FD | MAC_ASYM_PAUSE | MAC_SYM_PAUSE to keep advertising what they
> did, even if this may or may not be 100% correct (lan9303 and mv88e6060
> are not gigabit, and I don't know if they do flow control properly), but
> these issues are not new.

Would almost be no different from what we do today. The exception would
be the lack of 1000HD, which I think should be included even though it
isn't common - because currently it will be included.

I also think that if we're going down this route and putting code to set
those capabilities in the DSA drivers, they need to be accompanied with
a comment stating that they are a guess and may not be correct.

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