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: <bcc81ea0-78e1-476e-928c-b873a064b479@lunn.ch>
Date: Fri, 26 Jul 2024 13:33:52 +0200
From: Andrew Lunn <andrew@...n.ch>
To: Paolo Abeni <pabeni@...hat.com>
Cc: Lucas De Marchi <lucas.demarchi@...el.com>,
	Florian Fainelli <f.fainelli@...il.com>,
	Jose Ignacio Tornos Martinez <jtornosm@...hat.com>,
	UNGLinuxDriver@...rochip.com, davem@...emloft.net,
	edumazet@...gle.com, gregkh@...uxfoundation.org, kuba@...nel.org,
	linux-kernel@...r.kernel.org, linux-usb@...r.kernel.org,
	mcgrof@...nel.org, netdev@...r.kernel.org,
	woojung.huh@...rochip.com, Masahiro Yamada <masahiroy@...nel.org>,
	linux-kbuild@...r.kernel.org
Subject: Re: [PATCH] net: usb: lan78xx: add weak dependency with micrel phy
 module

On Thu, Jul 25, 2024 at 11:53:54AM +0200, Paolo Abeni wrote:
> On 7/25/24 08:50, Lucas De Marchi wrote:
> > if you are saying that the build system should automatically convert
> > this:
> > 
> > 	config USB_LAN78XX
> > 		tristate "Microchip LAN78XX Based USB Ethernet Adapters"
> > 		select MII
> > 		select PHYLIB
> > 		select MICROCHIP_PHY
> > 		select FIXED_PHY
> > 		select CRC32
> > 
> > into (for my config):
> > 
> > 	MODULE_WEAKDEP("mii");
> > 	MODULE_WEAKDEP("microchip");
> > 
> > then humn... why is CONFIG_MICREL (being added in this patch) not there?
> > It seems even if we automatically derive that information it wouldn't
> > fix the problem Jose is trying to solve.
> 
> I hoped that the 'weak dependency' towards mii and microchip could be
> inferred greping for 'request_module()' in the relevant code, but apparently
> it's not the case.

Nope. The module is not explicitly loaded by this driver. The PHY core
will look at ID registers in the PHY to determine what it is, and then
load a module which says it drives that ID.

There are also pin compatible PHYs, so it is possible a different
version of the LAN78xx USB dongle could need a different PHY
driver. So you might need multiple of these week dependencies.

And there are many boards using for example the FEC, with many
different PHYs in use, since Freescale was never really a PHY vendor,
its not really paired with a Freescale PHY.

As i said, whacker a mole.

So you cannot use this to determine what PHY driver goes into the
initramfs.

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.

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.

	Andrew


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ