Message-ID: <YsQIjC7UpcGWJovx@shell.armlinux.org.uk>
Date:   Tue, 5 Jul 2022 10:46:52 +0100
From:   "Russell King (Oracle)" <linux@...linux.org.uk>
To:     Andrew Lunn <andrew@...n.ch>,
        Heiner Kallweit <hkallweit1@...il.com>
Cc:     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: [PATCH RFC net-next v2 0/5] net: dsa: always use phylink

A new revision of the series which incorporates changes that Marek
suggested. Specifically, the changes are:

1. Patch 2 - use the phylink_get_caps method in mv88e6xxx to get the
   default interface rather than re-using port_max_speed_mode()

2. Patch 4 - if no default interface is provided, use the supported
   interface mask to search for the first interface that gives the
   fastest speed.

3. Patch 5 - now also removes the port_max_speed_mode() method

 drivers/net/dsa/b53/b53_common.c       |   3 +-
 drivers/net/dsa/bcm_sf2.c              |   3 +-
 drivers/net/dsa/hirschmann/hellcreek.c |   3 +-
 drivers/net/dsa/lantiq_gswip.c         |   6 +-
 drivers/net/dsa/microchip/ksz_common.c |   3 +-
 drivers/net/dsa/mt7530.c               |   3 +-
 drivers/net/dsa/mv88e6xxx/chip.c       | 136 +++++++++++++++---------------
 drivers/net/dsa/mv88e6xxx/chip.h       |   6 +-
 drivers/net/dsa/mv88e6xxx/port.c       |  32 -------
 drivers/net/dsa/mv88e6xxx/port.h       |   5 --
 drivers/net/dsa/ocelot/felix.c         |   3 +-
 drivers/net/dsa/qca/ar9331.c           |   3 +-
 drivers/net/dsa/qca8k.c                |   3 +-
 drivers/net/dsa/realtek/rtl8365mb.c    |   3 +-
 drivers/net/dsa/sja1105/sja1105_main.c |   3 +-
 drivers/net/dsa/xrs700x/xrs700x.c      |   3 +-
 drivers/net/phy/phylink.c              | 150 ++++++++++++++++++++++++++++++---
 include/linux/phylink.h                |   5 ++
 include/net/dsa.h                      |   3 +-
 net/dsa/port.c                         |  47 +++++++----
 20 files changed, 270 insertions(+), 153 deletions(-)

On Wed, Jun 29, 2022 at 01:49:57PM +0100, Russell King (Oracle) wrote:
> Mostly the same as the previous RFC, except:
> 
> 1) incldues the phylink_validate_mask_caps() function
> 2) has Marek's idea of searching the supported_interfaces bitmap for the
>    fastest interface we can use
> 3) includes a final patch to add a print which will be useful to hear
>    from people testing it.
> 
> Some of the questions from the original RFC remain though, so I've
> included that text below. I'm guessing as they remain unanswered that
> no one has any opinions on them?
> 
>  drivers/net/dsa/b53/b53_common.c       |   3 +-
>  drivers/net/dsa/bcm_sf2.c              |   3 +-
>  drivers/net/dsa/hirschmann/hellcreek.c |   3 +-
>  drivers/net/dsa/lantiq_gswip.c         |   6 +-
>  drivers/net/dsa/microchip/ksz_common.c |   3 +-
>  drivers/net/dsa/mt7530.c               |   3 +-
>  drivers/net/dsa/mv88e6xxx/chip.c       |  53 ++++--------
>  drivers/net/dsa/ocelot/felix.c         |   3 +-
>  drivers/net/dsa/qca/ar9331.c           |   3 +-
>  drivers/net/dsa/qca8k.c                |   3 +-
>  drivers/net/dsa/realtek/rtl8365mb.c    |   3 +-
>  drivers/net/dsa/sja1105/sja1105_main.c |   3 +-
>  drivers/net/dsa/xrs700x/xrs700x.c      |   3 +-
>  drivers/net/phy/phylink.c              | 148 ++++++++++++++++++++++++++++++---
>  include/linux/phylink.h                |   5 ++
>  include/net/dsa.h                      |   3 +-
>  net/dsa/port.c                         |  47 +++++++----
>  17 files changed, 215 insertions(+), 80 deletions(-)
> 
> On Fri, Jun 24, 2022 at 12:41:26PM +0100, Russell King (Oracle) wrote:
> > Hi,
> > 
> > Currently, the core DSA code conditionally uses phylink for CPU and DSA
> > ports depending on whether the firmware specifies a fixed-link or a PHY.
> > If either of these are specified, then phylink is used for these ports,
> > otherwise phylink is not, and we rely on the DSA drivers to "do the
> > right thing". However, this detail is not mentioned in the DT binding,
> > but Andrew has said that this behaviour has always something that DSA
> > wants.
> > 
> > mv88e6xxx has had support for this for a long time with its "SPEED_MAX"
> > thing, which I recently reworked to make use of the mac_capabilities in
> > preparation to solving this more fully.
> > 
> > This series is an experiment to solve this properly, and it does this
> > in two steps.
> > 
> > The first step consists of the first two patches. Phylink needs to
> > know the PHY interface mode that is being used so it can (a) pass the
> > right mode into the MAC/PCS etc and (b) know the properties of the
> > link and therefore which speeds can be supported across it.
> > 
> > In order to achieve this, the DSA phylink_get_caps() method has an
> > extra argument added to it so that DSA drivers can report the
> > interface mode that they will be using for this port back to the core
> > DSA code, thereby allowing phylink to be initialised with the correct
> > interface mode.
> > 
> > Note that this can only be used for CPU and DSA ports as "user" ports
> > need a different behaviour - they rely on getting the interface mode
> > from phylib, which will only happen if phylink is initialised with
> > PHY_INTERFACE_MODE_NA. Unfortunately, changing this behaviour is likely
> > to cause widespread regressions.
> > 
> > Obvious questions:
> > 1. Should phylink_get_caps() be augmented in this way, or should it be
> >    a separate method?
> > 
> > 2. DSA has traditionally used "interface mode for the maximum supported
> >    speed on this port" where the interface mode is programmable (via
> >    its internal port_max_speed_mode() method) but this is only present
> >    for a few of the sub-drivers. Is reporting the current interface
> >    mode correct where this method is not implemented?
> > 
> > The second step is to introduce a function that allows phylink to be
> > reconfigured after creation time to operate at max-speed fixed-link
> > mode for the PHY interface mode, also using the MAC capabilities to
> > determine the speed and duplex mode we should be using.
> > 
> > Obvious questions:
> > 1. Should we be allowing half-duplex for this?
> > 2. If we do allow half-duplex, should we prefer fastest speed over
> >    duplex setting, or should we prefer fastest full-duplex speed
> >    over any half-duplex?
> > 3. How do we sanely switch DSA from its current behaviour to always
> >    using phylink for these ports without breakage - this is the
> >    difficult one, because it's not obvious which drivers have been
> >    coded to either work around this quirk of the DSA implementation.
> >    For example, if we start forcing the link down before calling
> >    dsa_port_phylink_create(), and we then fail to set max-fixed-link,
> >    then the CPU/DSA port is going to fail, and we're going to have
> >    lots of regressions.
> > 
> > Please look at the patches and make suggestions on how we can proceed
> > to clean up this quirk of DSA.
> 
> -- 
> RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
> FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!
> 

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

Powered by blists - more mailing lists