[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ZNS3ePZssRCveaDd@shell.armlinux.org.uk>
Date: Thu, 10 Aug 2023 11:10:00 +0100
From: "Russell King (Oracle)" <linux@...linux.org.uk>
To: Oleksij Rempel <o.rempel@...gutronix.de>
Cc: Marek Vasut <marex@...x.de>, Andrew Lunn <andrew@...n.ch>,
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 06:32:42AM +0200, Oleksij Rempel wrote:
> On Thu, Aug 10, 2023 at 02:49:55AM +0200, Marek Vasut wrote:
> > On 8/10/23 00:06, Andrew Lunn wrote:
> > > On Wed, Aug 09, 2023 at 11:34:19PM +0200, Marek Vasut wrote:
> > > > On 8/9/23 15:40, Andrew Lunn wrote:
> > > > > > > Hm.. how about officially defining this PHY as the clock provider and disable
> > > > > > > PHY automatic hibernation as long as clock is acquired?
> > > > > > >
> > > > > > Sorry, I don't know much about the clock provider/consumer, but I think there
> > > > > > will be more changes if we use clock provider/consume mechanism.
> > > > >
> > > > > Less changes is not always best. What happens when a different PHY is
> > > > > used?
> > > >
> > > > Then the system wouldn't be affected by this AR803x specific behavior.
> > >
> > > Do you know it really is specific to the AR803x? Turning the clock off
> > > seams a reasonable thing to do when saving power, or when there is no
> > > link partner.
> >
> > This hibernation behavior seem specific to this PHY, I haven't seen it on
> > another PHY connected to the EQoS so far.
>
> Hm.. if I see it correctly I have right now kind of similar issues with
> Microchip KSZ9893 switch attached to EQoS. The switch is clock
> provider and I need to make sure that switch has CPU port enabled before
> probing the ethernet controller.
... and Cadence macb.
So, this is a thing, and we need to be able to cater for it.
Can we agree that:
(a) some ethernet MAC controllers need the RGMII receive clock to
function.
(b) IEEE 802.3 permits clocks to be disabled when entering EEE low
power state, and there is a defined control bit to allow this to
happen - so IEEE 802.3 _recognises_ that some MAC controllers need
this clock whereas others do not.
Therefore:
(c) Given that IEEE 802.3 appears to recognise this, we should add
some sort of control to phylib so that MACs can tell phylib that they
require the receive clock to always be present.
(d) We need to ensure that PHY drivers respect that bit and program
the hardware appropriately to ensure that where a MAC always needs
a receive clock, it is maintained.
(e) MACs that always need the receive clock enabled need to indicate
to phylib/phylink that this is the case.
My suggestion is to use a bit on the PHY device dev_flags (bit 30)
for this.
--
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