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: <CAK7LNARg-xxm3FecQ654OnxcMGtc8BjsXmZsymaNKnr_6sM=zw@mail.gmail.com>
Date: Sun, 28 Jul 2024 16:37:16 +0900
From: Masahiro Yamada <masahiroy@...nel.org>
To: Jose Ignacio Tornos Martinez <jtornosm@...hat.com>
Cc: 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

On Fri, Jul 26, 2024 at 9:15 PM Jose Ignacio Tornos Martinez
<jtornosm@...hat.com> 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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ