netdev - Re: [PATCH v2 net-next 2/2] net: phy: air_en8811h: Add the Airoha EN8811H PHY driver

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: <Zebf5UvqWjVyunFU@shell.armlinux.org.uk>
Date: Tue, 5 Mar 2024 09:03:33 +0000
From: "Russell King (Oracle)" <linux@...linux.org.uk>
To: Eric Woudstra <ericwouds@...il.com>
Cc: Andrew Lunn <andrew@...n.ch>, "David S. Miller" <davem@...emloft.net>,
	Eric Dumazet <edumazet@...gle.com>,
	Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>,
	Rob Herring <robh+dt@...nel.org>,
	Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
	Conor Dooley <conor+dt@...nel.org>,
	Heiner Kallweit <hkallweit1@...il.com>,
	Matthias Brugger <matthias.bgg@...il.com>,
	AngeloGioacchino Del Regno <angelogioacchino.delregno@...labora.com>,
	Frank Wunderlich <frank-w@...lic-files.de>,
	Daniel Golle <daniel@...rotopia.org>,
	Lucien Jheng <lucien.jheng@...oha.com>,
	Zhi-Jun You <hujy652@...tonmail.com>, netdev@...r.kernel.org,
	devicetree@...r.kernel.org
Subject: Re: [PATCH v2 net-next 2/2] net: phy: air_en8811h: Add the Airoha
 EN8811H PHY driver

On Tue, Mar 05, 2024 at 09:19:41AM +0100, Eric Woudstra wrote:
> The main reason I have it in config_init() is that by then the
> rootfs is available. The EN8811H does not depend on the firmware
> to respond to get_features(). It is therefore possible to not
> have the firmware in initramfs or included in the kernel image.
> I could not get this result using EPROBE_DEFER, I think this is
> not an option in phylink.

I think you're slightly confused there. It's not specific to phylink.

It's also not an option when using phy_connect()/phy_connect_direct()
from .ndo_open as well, or looking up the PHY to then use phy_attach()/
phy_attach_direct(). One can structure the code using phylink just
the same way one would structure the code using phylib in this respect.

.ndo_open can't handle EPROBE_DEFER. EPROBE_DEFER is so named because
it defers _driver_ _probing_ and thus is only appropriate to be
returned from a device driver .probe method. .ndo_open is not a device
driver probe method and thus EPROBE_DEFER must not be returned from it.

The only option in .ndo_open is to fail the attempt to open the network
device, at which point userspace will report an error and give up
opening that network device - it won't retry.

In summary, this isn't something which is specific to phylink.

The only way I can see around this problem would be to look up the
PHY in order to get a pointer to the struct phy_device in the network
device's probe function, and attach the PHY there _before_ you register
the network device. You can then return EPROBE_DEFER and, because you
are returning it in a .probe function, the probe will be retried once
other probes in the system (such as your PHY driver) have finished.
This also means that userspace doesn't see the appearance of the
non-functional network device until it's ready, and thus can use
normal hotplug mechanisms to notice the network device.

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