[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20240724145458.440023-1-jtornosm@redhat.com>
Date: Wed, 24 Jul 2024 16:54:54 +0200
From: Jose Ignacio Tornos Martinez <jtornosm@...hat.com>
To: gregkh@...uxfoundation.org
Cc: UNGLinuxDriver@...rochip.com,
andrew@...n.ch,
davem@...emloft.net,
edumazet@...gle.com,
jtornosm@...hat.com,
kuba@...nel.org,
linux-kernel@...r.kernel.org,
linux-usb@...r.kernel.org,
netdev@...r.kernel.org,
pabeni@...hat.com,
woojung.huh@...rochip.com,
lucas.demarchi@...el.com,
mcgrof@...nel.org
Subject: Re: [PATCH] net: usb: lan78xx: add weak dependency with micrel phy module
Hello Greg,
> Agree, this isn't ok, if you have a real dependancy, then show it as a
> real one please with the tools that we have to show that.
IMHO, I think it can be very useful.
Apart from the comments trying to answer Andrew, let me try to explain
better:
I am trying to solve dependencies that are not declared in anyway, but
without modifying the normal kernel behavior, for special cases in which
some modules are automatically loaded when something external is needed
or detected. For this cases, user tools like dracut don't have anyway to
detect this and if we a use a normal soft dependency, the modules will be
always loaded in advance.
Yes, it is a real dependency, but for this case, some phy modules are
possible and I think it doesn't make sense to load all the phy that could
be possible in advance, because there is an internal mechanism to only load
the necessary one (the associated phy is read using mdio bus and then
the associated phy module is loaded during runtime by means of the
function phy_request_driver_module).
I think it is better to load only the necessary modules and have only in
initramfs the necessary modules.
Here you can find the complete/original justification for this:
https://github.com/kmod-project/kmod/commit/05828b4a6e9327a63ef94df544a042b5e9ce4fe7
Please, take into account that this is the first usage of this feature,
lan78xx can be completed (others possible phy modules can be added) and it
can be considered by other modules in the same situation.
Let me add in the thread to the other people that have been involved.
Thanks
Best regards
José Ignacio
Powered by blists - more mailing lists