netdev - Re: [PATCH RFC net-next 0/4] net: dsa: always use 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]

Date:   Wed, 29 Jun 2022 10:43:23 +0100
From:   "Russell King (Oracle)" <linux@...linux.org.uk>
To:     Andrew Lunn <andrew@...n.ch>
Cc:     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,
        Marek Behún <kabel@...nel.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 0/4] net: dsa: always use phylink

On Wed, Jun 29, 2022 at 09:18:10AM +0200, Andrew Lunn wrote:
> > I should point out that if a DSA port can be programmed in software to
> > support both SGMII and 1000baseX, this will end up selecting SGMII
> > irrespective of what the hardware was wire-strapped to and how it was
> > initially configured. Do we believe that would be acceptable?
> 
> I'm pretty sure the devel b board has 1000BaseX DSA links between its
> two switches. Since both should end up SGMII that should be O.K.

Would such a port have a programmable C_Mode, and would it specify that
it supports both SGMII and 1000BaseX ? Without going through a lot of
boards and documentation for every switch, I can't say.

I don't think we can come to any conclusion on what the right way to
deal with this actually is - we don't have enough information about how
this is used across all the platforms we have. I think we can only try
something, get it merged into net-next, and wait to see whether anyone
complains.

When we have a CPU or DSA port without a fixed-link, phy or sfp specified,
I think we should:
(a) use the phy-mode property if present, otherwise,
(b,i) have the DSA driver return the interface mode that it wants to use
for max speed for CPU and DSA ports.
(b,ii) in the absence of the DSA driver returning a valid interface mode,
we use the supported_interfaces to find an interface which gives the
maximum speed (irrespective of duplex?) that falls within the
mac capabilities.

If all those fail, then things will break, and we will have to wait for
people to report that breakage. Does this sound a sane approach, or
does anyone have any other suggestions how to solve this?

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