netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Florian Fainelli <f.fainelli@gmail.com>
To: Lucas De Marchi <lucas.demarchi@intel.com>, Andrew Lunn <andrew@lunn.ch>
Cc: Jose Ignacio Tornos Martinez <jtornosm@redhat.com>,
	UNGLinuxDriver@microchip.com, davem@davemloft.net,
	edumazet@google.com, gregkh@linuxfoundation.org, kuba@kernel.org,
	linux-kernel@vger.kernel.org, linux-usb@vger.kernel.org,
	mcgrof@kernel.org, netdev@vger.kernel.org, pabeni@redhat.com,
	woojung.huh@microchip.com
Subject: Re: [PATCH] net: usb: lan78xx: add weak dependency with micrel phy module
Date: Wed, 24 Jul 2024 21:42:48 -0700	[thread overview]
Message-ID: <32be761b-cebc-48e4-a36f-bbf90654df82@gmail.com> (raw)
In-Reply-To: <v6uovbn7ld3vlym65twtcvximgudddgvvhsh6heicbprcs5ii3@nernzyc5vu3i>



On 7/24/2024 9:25 PM, Lucas De Marchi wrote:
> On Thu, Jul 25, 2024 at 12:57:05AM GMT, Andrew Lunn wrote:
>>> For the commented case, I have included only one phy because it is 
>>> the hardware
>>> that I have, but other phy devices (modules) are possible and they 
>>> can be some.
>>
>> So this the whole whacker a mole problem. It works for you but fails
>> for 99% of users. How is this helping us?
> 
> no, this is the first instance that was found/added.
> 
> if you declare a softdep what happens is that the dep is loaded first
> (needed or not) and your module is loaded after that
> 
> if you declare a weakdep, you are just instructing the tools that the
> module may or may not be needed.  Any module today that does a
> request_module("foo") could be a candidate to migrate from
> MODULE_SOFTDEP("pre: foo") to the new weakdep, as long as it handles
> properly the module being loaded ondemand as opposed to using
> request_module() to just synchronize the module being loaded.
> 
>>
>> Maybe a better solution is to first build an initramfs with
>> everything, plus the kitchen sink. Boot it, and then look at what has
>> been loaded in order to get the rootfs mounted. Then update the
>> initramfs with just what is needed? That should be pretty generic,
>> with throw out networking ig NFS root is not used, just load JFFS2 and
>> a NAND driver if it was used for the rootfs, etc.
> 
> that works for development systems or if you are fine tuning it for each
> system you have. It doesn't work for a generic distro with the kitchen
> sink of modules and still trying to minimize the initrd without end user
> intervention. So it works for 99% of users.

OK, but 'config USB_LAN78XX' does have a number of 'select' meaning 
those are hard functional dependencies, and so those should be more than 
a hint that these modules are necessary. Why should we encode that 
information twice: once in Kconfig and another time within the module .c 
file itself? Cannot we have better tooling to help build an initramfs 
which does include everything that has been selected?
-- 
Florian

  reply	other threads:[~2024-07-25  4:42 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-07-24 10:23 [PATCH] net: usb: lan78xx: add weak dependency with micrel phy module Jose Ignacio Tornos Martinez
2024-07-24 11:49 ` Andrew Lunn
2024-07-24 13:36   ` Greg KH
2024-07-24 14:46     ` Jose Ignacio Tornos Martinez
2024-07-24 15:31       ` Florian Fainelli
2024-07-24 14:54     ` Jose Ignacio Tornos Martinez
2024-07-24 16:10       ` Jose Ignacio Tornos Martinez
2024-07-24 22:57         ` Andrew Lunn
2024-07-25  4:25           ` Lucas De Marchi
2024-07-25  4:42             ` Florian Fainelli [this message]
2024-07-25  6:50               ` Lucas De Marchi
2024-07-25  9:53                 ` Paolo Abeni
2024-07-26 11:33                   ` Andrew Lunn
2024-07-26 12:15                     ` Jose Ignacio Tornos Martinez
2024-07-26 20:59                       ` Andrew Lunn
2024-07-27 17:15                         ` Dragan Simic
2024-07-27 23:29                           ` Andrew Lunn
2024-07-28 14:10                             ` Dragan Simic
2024-07-28 19:45                               ` Andrew Lunn
2024-07-28 20:46                                 ` Dragan Simic
2024-07-28 20:57                                   ` Andrew Lunn
2024-07-29  4:43                                     ` Dragan Simic
2024-07-29  6:13                                       ` Greg KH
2024-07-29  6:29                                         ` Dragan Simic
2024-07-29  8:34                                           ` Jose Ignacio Tornos Martinez
2024-07-29  9:28                                             ` Dragan Simic
2024-07-29 12:32                                               ` Jose Ignacio Tornos Martinez
2024-07-29 18:56                                                 ` Andrew Lunn
2024-07-30  7:55                                                   ` Jose Ignacio Tornos Martinez
2024-07-28  7:37                       ` Masahiro Yamada
2024-07-28  9:53                         ` Dragan Simic
2024-07-26 14:49           ` Jakub Kicinski
2024-07-26 21:15             ` Andrew Lunn
2024-07-29  8:37               ` Jose Ignacio Tornos Martinez
2024-07-29 12:42                 ` Andrew Lunn

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=32be761b-cebc-48e4-a36f-bbf90654df82@gmail.com \
    --to=f.fainelli@gmail.com \
    --cc=UNGLinuxDriver@microchip.com \
    --cc=andrew@lunn.ch \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=jtornosm@redhat.com \
    --cc=kuba@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=lucas.demarchi@intel.com \
    --cc=mcgrof@kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=woojung.huh@microchip.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).