netdev - Re: [PATCH net v3 2/2] net: fec: Suspend the PHY on probe

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]

Message-ID: <ZflSE8AaYLE3Ri8L@shell.armlinux.org.uk>
Date: Tue, 19 Mar 2024 08:51:31 +0000
From: "Russell King (Oracle)" <linux@...linux.org.uk>
To: John Ernberg <john.ernberg@...ia.se>
Cc: Maxime Chevallier <maxime.chevallier@...tlin.com>,
	Wei Fang <wei.fang@....com>, Shenwei Wang <shenwei.wang@....com>,
	Clark Wang <xiaoning.wang@....com>,
	NXP Linux Team <linux-imx@....com>,
	"David S. Miller" <davem@...emloft.net>,
	Eric Dumazet <edumazet@...gle.com>,
	Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>,
	Heiner Kallweit <hkallweit1@...il.com>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Andrew Lunn <andrew@...n.ch>
Subject: Re: [PATCH net v3 2/2] net: fec: Suspend the PHY on probe

On Tue, Mar 19, 2024 at 08:37:44AM +0000, John Ernberg wrote:
> There is also a case where the phy driver module is not automatically 
> loaded, in cases where request_module() fails, either due to the 
> userspace helper feature being compiled out or other reasons, and the 
> module is loaded manually later. I suspect for reasons like these the 
> genphy probe happens so late. My solution here doesn't cover non-loaded 
> modules either, but this could maybe be covered by moving phy_suspend() 
> to phy_probe(). Unless there is an even more clever way to go about it 
> which I can't see from inexperience.

Note that in the case where the PHY driver module is loaded late,
phy_probe() won't be called for the PHY until that happens.

I would say if one wants a platform to behave with minimal power
consumption, that is something that has to be done across the
software stack, and that includes the boot firmware. So, if one
wants the PHY to be in a low power state at boot time, then
firmware needs to ensure that happens.

Trying to shoe-horn that into the kernel isn't going to work
because we get to decide what to do with the PHY way too late
(due to PHY drivers being modular and on the rootfs.)

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