Linux kbuild/kconfig development
 help / color / mirror / Atom feed
From: Dragan Simic <dsimic@manjaro.org>
To: Andrew Lunn <andrew@lunn.ch>
Cc: Jose Ignacio Tornos Martinez <jtornosm@redhat.com>,
	UNGLinuxDriver@microchip.com, davem@davemloft.net,
	edumazet@google.com, f.fainelli@gmail.com,
	gregkh@linuxfoundation.org, kuba@kernel.org,
	linux-kbuild@vger.kernel.org, linux-kernel@vger.kernel.org,
	linux-usb@vger.kernel.org, lucas.demarchi@intel.com,
	masahiroy@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: Sun, 28 Jul 2024 22:46:28 +0200	[thread overview]
Message-ID: <98d200777d62dc9b447557b2758613e5@manjaro.org> (raw)
In-Reply-To: <3a3f49b5-45b2-4999-a364-60d035bbd11f@lunn.ch>

On 2024-07-28 21:45, Andrew Lunn wrote:
>> Basically, the way I see it, weakdeps are the right solution for the
>> problem at hand, i.e. for the generation of the initial ramdisk with
>> all the possible PHY driver modules.
> 
> Sorry, but i still don't see how this works.
> 
> Say you get this one patch merged. What then? You throw all other PHY
> drivers which don't have a weakdep out of the initramfs? That
> potentially breaks around 200 MAC drivers who need those PHYs you have
> discarded.

Actually, no PHY drivers can be thrown out of an initial ramdisk by this
patch, [1] simply because no PHY drivers not needed for a specific 
system
shouldn't be included there before, unless they were added specifically
by the utilities that created the initial ramdisk, but that's beyond the
dependencies that the kernel provides in /lib/modules, and beyond what
can be obtained by automatic detection using /sys/devices on a 
particular
system.  That's all a result of this specific module dependency being
unknown before, at the kernel level.

In other words, this patch doesn't subtract anything.  Instead, it just
adds a weakdep link between the lan78xx and micrel modules, so the 
kernel
itself can report that dependency, which may actually result in one more
PHY driver added to a generated initial ramdisk.

[1] 
https://lore.kernel.org/netdev/20240724102349.430078-1-jtornosm@redhat.com/

  reply	other threads:[~2024-07-28 20:46 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20240724145458.440023-1-jtornosm@redhat.com>
     [not found] ` <20240724161020.442958-1-jtornosm@redhat.com>
     [not found]   ` <8a267e73-1acc-480f-a9b3-6c4517ba317a@lunn.ch>
     [not found]     ` <v6uovbn7ld3vlym65twtcvximgudddgvvhsh6heicbprcs5ii3@nernzyc5vu3i>
     [not found]       ` <32be761b-cebc-48e4-a36f-bbf90654df82@gmail.com>
2024-07-25  6:50         ` [PATCH] net: usb: lan78xx: add weak dependency with micrel phy module 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 [this message]
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

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=98d200777d62dc9b447557b2758613e5@manjaro.org \
    --to=dsimic@manjaro.org \
    --cc=UNGLinuxDriver@microchip.com \
    --cc=andrew@lunn.ch \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=f.fainelli@gmail.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=jtornosm@redhat.com \
    --cc=kuba@kernel.org \
    --cc=linux-kbuild@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=lucas.demarchi@intel.com \
    --cc=masahiroy@kernel.org \
    --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