Date:   Mon, 18 Jul 2022 22:42:29 +0200
From:   Andrew Lunn <andrew@...n.ch>
To:     "Russell King (Oracle)" <linux@...linux.org.uk>
Cc:     Andy Shevchenko <andriy.shevchenko@...ux.intel.com>,
        Vladimir Oltean <olteanv@...il.com>,
        Heiner Kallweit <hkallweit1@...il.com>,
        Alexandre Belloni <alexandre.belloni@...tlin.com>,
        Alvin __ipraga <alsi@...g-olufsen.dk>,
        Claudiu Manoil <claudiu.manoil@....com>,
        Daniel Scally <djrscally@...il.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>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Hauke Mehrtens <hauke@...ke-m.de>,
        Heikki Krogerus <heikki.krogerus@...ux.intel.com>,
        Jakub Kicinski <kuba@...nel.org>,
        Kurt Kanzenbach <kurt@...utronix.de>,
        Landen Chao <Landen.Chao@...iatek.com>,
        Linus Walleij <linus.walleij@...aro.org>,
        linux-acpi@...r.kernel.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>,
        "Rafael J. Wysocki" <rafael@...nel.org>,
        Sakari Ailus <sakari.ailus@...ux.intel.com>,
        Sean Wang <sean.wang@...iatek.com>,
        UNGLinuxDriver@...rochip.com,
        Vivien Didelot <vivien.didelot@...il.com>,
        Woojung Huh <woojung.huh@...rochip.com>,
        Marek Behún <kabel@...nel.org>
Subject: Re: [PATCH net-next 2/6] software node: allow named software node to
 be created

> > Just for my learning, why PHY uses "fixed-link" instead of relying on a
> > (firmware) graph? It might be the actual solution to your problem.
> 
> That's a question for Andrew, but I've tried to solicit his comments on
> several occasions concerning this "feature" of DSA but I keep getting
> no reply. Honestly, I don't know the answer to your question.
> 
> The only thing that I know is that Andrew has been promoting this
> feature where a switch port, whether it be connected to the CPU or
> to another switch, which doesn't specify any link parameters will
> automatically use the fastest "phy interface mode" and the fastest
> link speed that can be supported by the DSA device.

This goes back to the very beginning of DSA, as far as i know. This
was before the times of DT. Platform data was used to describe the
switch tree, and it was pretty minimalist. It just listed the ports of
the switches and their names. The 'cpu' port had the name 'cpu', and
DSA ports either did not have a name, or 'dsa'. I don't
remember. There was also a table describing the routing between
switches in the tree. The platform data had nothing to describe
interface speeds, and i'm not sure phylib was even involved to control
the integrated PHYs. Marvell switches would power up their PHYs in
autoneg mode, meaning they just worked. In order to make the CPU port
work, which did not have a PHY, the driver would configure the CPU
port into its fastest mode. Same for the DSA ports. A Marvell Switch
connected to a Marvell SoC NIC worked.

Sometime later DT became the way to describe ARM boards, and pretty
much all boards with switches were ARM boards. If i remember
correctly, Florian did the first binding, which was basically
translate the platform data straight into DT. Since the platform data
had no way to describe port speed, the DT binding had no way to
describe port speed. It just kept on defaulting to the maximum speed.

The DT world evolved, and DT bindings were produced for phylib.

At some point, DSA got an interface to phylib. Maybe it was there from
the beginning, maybe it was added later. I don't know. As a result,
the DT properties for phylib became valid for switch user ports.

Without looking at git, i'm a bit hazy why fixed-link was introduced
for CPU and DSA ports. At some point in time, i was asked to make a
Marvell switch work with a Freescale FEC. The FEC had a Fast Ethernet,
where as the switch CPU port was 1G. It could be that in order to make
this work, i added fixed-link support to CPU ports, so i could specify
the CPU port speed, rather than use the default which would not work.

At some point, i had a board with an RGMII interface used as a DSA
link between two switches, and i needed to specify the RGMII
delays. It could of been using a fixed-link allowed the phy-mode to be
specified for a DSA port, thus allowing the delays to be specified?

Basically, fixed-phy for CPU and DSA was added to solve a limitation
of the default fastest port speed not always working.

With time, more vendors got behind DSA and switches other than Marvell
were added. There was not much documentation about the expectations of
switch drivers, and i doubt this default maximum speed behaviour of
CPU ports was documented. I probably commented on earlier drivers that
fixed-link could be used, or that the Marvell behaviour could be
copied.

And some devices probably power up ports at their maximum speed,
others can probably be strapped to specific modes. Some drivers
default to maximum speed, others required fixed links to specific the
speed. As Russell says, code inspection is not enough to tell what is
going on.

	Andrew

Powered by blists - more mailing lists