[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ZNT18BsOZPGLN+Dj@shell.armlinux.org.uk>
Date: Thu, 10 Aug 2023 15:36:32 +0100
From: "Russell King (Oracle)" <linux@...linux.org.uk>
To: Andrew Lunn <andrew@...n.ch>
Cc: Oleksij Rempel <o.rempel@...gutronix.de>, Marek Vasut <marex@...x.de>,
Wei Fang <wei.fang@....com>,
"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
"David S. Miller" <davem@...emloft.net>,
Eric Dumazet <edumazet@...gle.com>,
Heiner Kallweit <hkallweit1@...il.com>,
Jakub Kicinski <kuba@...nel.org>,
Oleksij Rempel <linux@...pel-privat.de>,
Paolo Abeni <pabeni@...hat.com>
Subject: Re: [PATCH] net: phy: at803x: Improve hibernation support on start up
On Thu, Aug 10, 2023 at 04:23:08PM +0200, Andrew Lunn wrote:
> On Thu, Aug 10, 2023 at 02:54:58PM +0100, Russell King (Oracle) wrote:
> > On Thu, Aug 10, 2023 at 03:49:24PM +0200, Andrew Lunn wrote:
> > > > > What will be the best way to solve this issue for DSA switches attached to
> > > > > MAC with RGMII RXC requirements?
> > > >
> > > > I have no idea - the problem there is the model that has been adopted
> > > > in Linux is that there is no direct relationship between the DSA switch
> > > > and the MAC like there is with a PHY.
> > >
> > > A clock provider/consumer relationship can be expressed in DT. The DSA
> > > switch port would provide the clock, rather than the PHY.
> >
> > Then we'll be in to people wanting to do it for PHYs as well, and as
> > we've recently discussed that isn't something we want because of the
> > dependencies it creates between mdio drivers and mac drivers.
> >
> > Wouldn't the same dependency issue also apply for a DSA switch on a
> > MDIO bus, where the MDIO bus is part of the MAC driver?
>
> We already have some level of circular dependencies with DSA, e.g. the
> MAC driver provides the MDIO bus with the switch on it. It registers
> the MDIO bus, causing the switch to probe. That probe fails because
> the MAC driver has not registered its interface yet, which is the CPU
> interface. We end up deferring the switch probe, and by the second
> attempt, the MAC is fully registered and the switch probes.
If that sequence occurs with a MAC that wants a clock from DSA, then
we're at a loss...
The DSA driver probe fails because the MAC hasn't fully registered
itself, so doesn't create the clock. The MAC driver tries to get the
clock but it doesn't exist, so it defers, tearing down the MDIO bus
in the process.
> The circular dependency with a clock consumer/provider between the MAC
> and switch will be worse. We would need to avoid getting the clock in
> the probe function. It would need to happen in during open, by which
> time the switch should be present. MAC drivers also typically connect
> to their PHY during open, not probe, so i don't see this as being too
> big a problem.
Providing nothing is happening in the MAC driver initialisation which
requires that clock, then that would be fine.
Removal should be possible provided the MAC driver doesn't need
anything before it removes the MDIO bus.
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!
Powered by blists - more mailing lists