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

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: <fa9fa543c4c8ca4e8ec54744e2e07efb@manjaro.org>
Date: Sun, 28 Jul 2024 11:53:08 +0200
From: Dragan Simic <dsimic@...jaro.org>
To: Masahiro Yamada <masahiroy@...nel.org>
Cc: Jose Ignacio Tornos Martinez <jtornosm@...hat.com>, andrew@...n.ch,
 UNGLinuxDriver@...rochip.com, davem@...emloft.net, edumazet@...gle.com,
 f.fainelli@...il.com, gregkh@...uxfoundation.org, kuba@...nel.org,
 linux-kbuild@...r.kernel.org, linux-kernel@...r.kernel.org,
 linux-usb@...r.kernel.org, lucas.demarchi@...el.com, mcgrof@...nel.org,
 netdev@...r.kernel.org, pabeni@...hat.com, woojung.huh@...rochip.com
Subject: Re: [PATCH] net: usb: lan78xx: add weak dependency with micrel phy
 module

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@...hat.com> 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@manjaro.org/
- 
https://lore.kernel.org/dri-devel/4e1e00422a14db4e2a80870afb704405da16fd1b.1718655077.git.dsimic@manjaro.org/T/#u
- 
https://lore.kernel.org/dri-devel/fdaf2e41bb6a0c5118ff9cc21f4f62583208d885.1718655070.git.dsimic@manjaro.org/T/#u