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: <20240729123244.18780-1-jtornosm@redhat.com>
Date: Mon, 29 Jul 2024 14:32:43 +0200
From: Jose Ignacio Tornos Martinez <jtornosm@...hat.com>
To: dsimic@...jaro.org
Cc: UNGLinuxDriver@...rochip.com,
	andrew@...n.ch,
	davem@...emloft.net,
	edumazet@...gle.com,
	f.fainelli@...il.com,
	gregkh@...uxfoundation.org,
	jtornosm@...hat.com,
	kuba@...nel.org,
	linux-kbuild@...r.kernel.org,
	linux-kernel@...r.kernel.org,
	linux-usb@...r.kernel.org,
	lucas.demarchi@...el.com,
	masahiroy@...nel.org,
	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 Dragan and others,

> I see and agree, but please note that other people highly disagree about
> that being an issue at all.  Thus, I'd suggest that you provide a 
> detailed
> explanation of why and how that presents an issue that weakdeps solve.
I think that the problem that I am trying to fix related to initramfs
generation is understood. At least what I tried to explain at the beginning
of this thread with my messages and the help of Lucas. But maybe you are  
right, so let me provide a more specific explanation.

The only thing that I could repeat and/remark is that I am not modifying
anything in the current kernel behavior, and specifically for this case 
(lan78xx) with a network driver and related phy modules: I am just trying
to add a flag (and nothing else) to complete the information of the
necessary modules to be collected by the tools that build the initramfs.

And if this information about the necessary modules is not correctly
collected, the kernel is not going to work from initramfs, Especially if
the network drivers are not working (because the phy module is not found),
some initial and necessary resources could not be available before and
after initramfs stage, because unless the network driver is unloaded and
loaded again after initramfs stage (then the phy modules would be available
from rootfs), it is going to be in the same situation, that is, not
correctly initialized and not working.

Including in the initramfs all the phy modules is an option but I think it
would be better to include only the necessary stuff (this is the default
behavior for the tools that are used to build the initramfs). This is valid
for embedded and not-embedded systems.

If this patch, to only add the related flag of the network driver to inform
about the possible phy modules, is rejected because a more general solution
is preferred, I would like to dig into it, at least to know if it is possible
to do better.
Maybe Andrew in other part of the thread, after the interesting comments
from Jakub, can help and provide some new (for me) inputs.

> Regarding Lima and Panfrost, I agree that weakdeps are a better solution
> than softdeps, but please see also harddeps. [1]  I'd appreciate if 
> you'd provide your opinion about the proposed harddeps.
> [1] 
> https://lore.kernel.org/linux-modules/04e0676b0e77c5eb69df6972f41d77cdf061265a.1721906745.git.dsimic@manjaro.org/T/#u
Ok, I will think more about it.
After a quick first look I agree with Lucas, but let's go little by little
(at least I don't have a lot of time before my holidays). 

Thanks

Best regards
José Ignacio