All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Russell King (Oracle)" <linux@armlinux.org.uk>
To: Andrew Lunn <andrew@lunn.ch>
Cc: "Vladimir Oltean" <vladimir.oltean@nxp.com>,
	netdev@vger.kernel.org, "Woojung Huh" <woojung.huh@microchip.com>,
	UNGLinuxDriver@microchip.com,
	"Vivien Didelot" <vivien.didelot@gmail.com>,
	"Florian Fainelli" <f.fainelli@gmail.com>,
	"Vladimir Oltean" <olteanv@gmail.com>,
	"David S. Miller" <davem@davemloft.net>,
	"Eric Dumazet" <edumazet@google.com>,
	"Jakub Kicinski" <kuba@kernel.org>,
	"Paolo Abeni" <pabeni@redhat.com>,
	"Michael Grzeschik" <m.grzeschik@pengutronix.de>,
	"Oleksij Rempel" <linux@rempel-privat.de>,
	"Thorsten Leemhuis" <regressions@leemhuis.info>,
	"Alvin Šipraga" <alsi@bang-olufsen.dk>,
	"Rasmus Villemoes" <linux@rasmusvillemoes.dk>,
	"Craig McQueen" <craig@mcqueen.id.au>
Subject: Re: [PATCH net] net: dsa: microchip: keep compatibility with device tree blobs with no phy-mode
Date: Thu, 18 Aug 2022 16:33:04 +0100	[thread overview]
Message-ID: <Yv5bsEpICDSuJUgs@shell.armlinux.org.uk> (raw)
In-Reply-To: <Yv5XL4KTLxukVhck@lunn.ch>

On Thu, Aug 18, 2022 at 05:13:51PM +0200, Andrew Lunn wrote:
> > It is important to note that phy_device_create() initializes
> > dev->interface = PHY_INTERFACE_MODE_GMII, and so, when we use
> > phylink_create(PHY_INTERFACE_MODE_NA), no one will override this, and we
> > will end up with a PHY_INTERFACE_MODE_GMII interface inherited from the
> > PHY.
> 
> Is this actually a bug?
> 
> With pure phylib, you should call one of the connect functions, which
> underneath calls phy_attach_direct() which has a phy_interface_t. So
> the default in practice does not matter.
> 
> > All this means that in order to maintain compatibility with device tree
> > blobs where the phy-mode property is missing, we need to allow the
> > "gmii" phy-mode and treat it as "internal".
> 
> of_get_phy_mode() returns PHY_INTERFACE_MODE_NA if the property is
> missing, which also suggests this is a bug.
> 
> I wonder if we have any ports which actually rely on
> PHY_INTERFACE_MODE_GMII?

Loads now. Florian contributed the code to phylink that detects when
DSA initialises phylink with PHY_INTERFACE_MODE_NA, and then looks at
phy->interface _before_ calling phy_attach_direct() - and this is how
we end up with PHY_INTERFACE_MODE_GMII.

See:

commit 4904b6ea1f9dbf47107f50b1c502a22d0160712d
Author: Florian Fainelli <f.fainelli@gmail.com>
Date:   Tue Dec 12 16:00:26 2017 -0800

    net: phy: phylink: Use PHY device interface if N/A

    We may not always be able to resolve a correct phy_interface_t value before
    actually connecting to the PHY device, when that happens, just have
    phylink_connect_phy() utilize what the PHY device/driver provided.

    Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>

submitted for 4.16-rc1. DSA then used this in:

commit aab9c4067d2389d0adfc9c53806437df7b0fe3d5
Author: Florian Fainelli <f.fainelli@gmail.com>
Date:   Thu May 10 13:17:36 2018 -0700

    net: dsa: Plug in PHYLINK support
...

for 4.18-rc1 to connect to its PHYs:

static int dsa_slave_phy_connect(struct net_device *slave_dev, int addr)
{
        struct dsa_port *dp = dsa_slave_to_port(slave_dev);
        struct dsa_switch *ds = dp->ds;

        slave_dev->phydev = mdiobus_get_phy(ds->slave_mii_bus, addr);
        if (!slave_dev->phydev) {
                netdev_err(slave_dev, "no phy at %d\n", addr);
                return -ENODEV;
        }

        return phylink_connect_phy(dp->pl, slave_dev->phydev);
}
...
        ret = phylink_of_phy_connect(dp->pl, port_dn, phy_flags);
        if (ret == -ENODEV) {
                /* We could not connect to a designated PHY or SFP, so use the
                 * switch internal MDIO bus instead
                 */
                ret = dsa_slave_phy_connect(slave_dev, dp->index);
                if (ret) {
                        netdev_err(slave_dev,
                                   "failed to connect to port %d: %d\n",
                                   dp->index, ret);
                        phylink_destroy(dp->pl);
                        return ret;
                }
        }

which will be used when there is no phy-handle property.

I extended the change in 4904b6ea1f9dbf47107f50b1c502a22d0160712d to also
apply to fwnode setups in:

commit a18e6521a7d95dae8c65b5b0ef6bbe624fbe808c
Author: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
Date:   Fri Nov 19 16:28:06 2021 +0000

    net: phylink: handle NA interface mode in phylink_fwnode_phy_connect()

because we were ending up with DSA drivers using PHY_INTERFACE_MODE_NA
inside phylink, and phylink has always special-cased that and drivers
have taken it to mean "give me all interface modes that are supported"
which is not what DSA should be using. It also gives a uniform and
understandable behaviour from phylink for DSA, rather than having
phylink behave one way (where no phy-mode and no phy-handle are
specified) but in a completely different way when phy-handle without
phy-mode is specified. It seemed to be the sensible thing to do, and
Florian agreed at the time.

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

  parent reply	other threads:[~2022-08-18 15:33 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-08-18 14:32 [PATCH net] net: dsa: microchip: keep compatibility with device tree blobs with no phy-mode Vladimir Oltean
2022-08-18 15:06 ` Alvin Šipraga
2022-08-18 15:18   ` Vladimir Oltean
2022-08-18 15:25     ` Alvin Šipraga
2022-08-18 15:13 ` Andrew Lunn
2022-08-18 15:21   ` Vladimir Oltean
2022-08-18 15:33   ` Russell King (Oracle) [this message]
2022-08-19 10:19 ` Rasmus Villemoes
2022-08-19 10:57   ` Vladimir Oltean
2022-08-19 11:47     ` Rasmus Villemoes
2022-08-19 16:41       ` Vladimir Oltean
2022-08-22 20:11         ` Tim Harvey
2022-08-19 23:32 ` Jakub Kicinski
2022-08-20 11:24   ` Vladimir Oltean
2022-08-23  1:00 ` patchwork-bot+netdevbpf

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Yv5bsEpICDSuJUgs@shell.armlinux.org.uk \
    --to=linux@armlinux.org.uk \
    --cc=UNGLinuxDriver@microchip.com \
    --cc=alsi@bang-olufsen.dk \
    --cc=andrew@lunn.ch \
    --cc=craig@mcqueen.id.au \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=f.fainelli@gmail.com \
    --cc=kuba@kernel.org \
    --cc=linux@rasmusvillemoes.dk \
    --cc=linux@rempel-privat.de \
    --cc=m.grzeschik@pengutronix.de \
    --cc=netdev@vger.kernel.org \
    --cc=olteanv@gmail.com \
    --cc=pabeni@redhat.com \
    --cc=regressions@leemhuis.info \
    --cc=vivien.didelot@gmail.com \
    --cc=vladimir.oltean@nxp.com \
    --cc=woojung.huh@microchip.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.