Re: [PATCH] net: usb: lan78xx: add weak dependency with micrel phy module

From: Dragan Simic
Date: Sun Jul 28 2024 - 05:53:24 EST

Hello Masahiro,

On 2024-07-28 09:37, Masahiro Yamada wrote:
On Fri, Jul 26, 2024 at 9:15 PM Jose Ignacio Tornos Martinez
<jtornosm@xxxxxxxxxx> wrote:
> What this does appear to do is differentiate between 'pre' which will
> load the kernel module before it is requested. Since there is no 'pre'
> for this, it seems pointless whacking this mole.
Precisely, we need to fix the lan78xx case with micrel phy (and other
possible phy modules) too, due to the commented issue generating initramfs
in order to include the phy module.

> What to me make more sense it to look at all the existing 'pre'
> drivers and determine if they can be converted to use this macro.
Of course, now that we have the possibility we can do this with other cases
that have been already detected (and fixed with a softdep pre) and others
still not detected (if anyone apart from lan78xx).

I am not familiar with MAC/PHY interface, but perhaps the
situation might be different on internal/external PHYs?

I do not know if "micrel" is an internal or an external PHY, though.

[1] internal PHY

Commit e57cf3639c323eeed05d3725fd82f91b349adca8 moved the
internal PHY code from drivers/net/usb/lan78xx.c
to drivers/net/phy/microchip.c

So, lan78xx.ko is likely to use microchip.ko

Perhaps, is the following useful?

MODULE_WEAKDEP("microchip"); /* internal PHY */

Or, is this the case for MODULE_SOFTDEP()?

[2] external PHY

When an external PHY device is connected, the MAC/PHY combination is
pretty much board-specific. We may end up with
a bunch of MODULE_WEAKDEP().

The second question is, is it so important to enable network
at the initramfs time? Personally, I am fine with having network
drivers in the root file system.

Is this useful when the root file system is nfs or something?

The troubles happen when the driver is probed during the initial
ramdisk stage, e.g. when a machine is rebooted with a USB adapter
plugged in. If the required dependent PHY driver module isn't also
found in the initial ramdisk, probing the main driver may actually
fail or (hopefully not) end up in some strange state.

If you have time, I'd suggest that you go through the following
related discussions, which should provide further clarification
and additional examples of such issues with initial ramdisks and
additional driver modules:

- https://lore.kernel.org/linux-modules/04e0676b0e77c5eb69df6972f41d77cdf061265a.1721906745.git.dsimic@xxxxxxxxxxx/
- https://lore.kernel.org/dri-devel/4e1e00422a14db4e2a80870afb704405da16fd1b.1718655077.git.dsimic@xxxxxxxxxxx/T/#u
- https://lore.kernel.org/dri-devel/fdaf2e41bb6a0c5118ff9cc21f4f62583208d885.1718655070.git.dsimic@xxxxxxxxxxx/T/#u