On Fri, Jul 26, 2024 at 9:15 PM Jose Ignacio Tornos Martinez
<jtornosm@xxxxxxxxxx> wrote:
>
> Hello Andrew,
>
> > 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).
>
> Thanks
>
> Best regards
> José Ignacio
>
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?
--
Best Regards
Masahiro Yamada
