netdev - Re: [PATCH] net: phy: at803x: Improve hibernation support on start up

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date: Thu, 10 Aug 2023 00:15:14 +0100
From: "Russell King (Oracle)" <linux@...linux.org.uk>
To: Marek Vasut <marex@...x.de>
Cc: Andrew Lunn <andrew@...n.ch>, Wei Fang <wei.fang@....com>,
	Oleksij Rempel <o.rempel@...gutronix.de>,
	"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 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.

I don't think it is AR803x specific behaviour. I think it is an
interesting stmmac behaviour, where it requires the clock from
the PHY in order to do even the most trivial things (like reset
itself.) That is a very interesting design decision.

how does stmmac hardware complete a power-on reset if it needs
the external clock from a PHY that itself might be in the process
of powering itself up and establishing its clocks...

There have been *hacks* to phylink requested over the years to
work around this peculiar behaviour by stmmac - and it seems that
it's not common behaviour.

This kind of thing might affect Cadence's macb driver as well, but
rather than it being a clock from the ethernet PHY, it seems to be
from the serdes PHY built in to the SoC - if I understand what's
reported in the proposed patch commit log (which I don't fully.)

In the case of stmmac, I don't think it's fair to blame the AR803x.
It's a hardware integration issue - the AR803x implementation which
works fine elsewhere has a problem with the stmmac implementation,
because design decisions made in both implementations end up being
incompatible with each other.

However, pair them with different implementations, and they're fine.

Given that stmmac requires a clock from the PHY, I'm of the opinion
that we need to have a way to tell phylib that "hey, this MAC must
always have a receive clock from the PHY, please arrange for that
to happen". AR803x needs to check that and arrange for the receive
clock to always be output. phylib can also use that to ensure that
when EEE mode is active in the PHY, clock-stop support is disabled...
and that's actually a key part to getting EEE properly implemented.

Clearly, the IEEE 802.3 folk catered for this issue when specifying
EEE, where some MACs must always be fed a receive clock, and so I
think phylib in Linux needs to recognise that this is A Thing that
it should allow MACs to specify.

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