Linux-Modules Archive on
 help / color / Atom feed
From: Heiner Kallweit <>
To: Lucas De Marchi <>, Jessica Yu <>
Cc: Linux Kernel Mailing List <>,,
	"" <>
Subject: Re: RFC: Handle hard module dependencies that are not symbol-based (r8169 + realtek)
Date: Wed, 8 Apr 2020 23:37:23 +0200
Message-ID: <> (raw)
In-Reply-To: <>

On 01.04.2020 23:20, Heiner Kallweit wrote:
> Currently we have no way to express a hard dependency that is not
> a symbol-based dependency (symbol defined in module A is used in
> module B). Use case:
> Network driver ND uses callbacks in the dedicated PHY driver DP
> for the integrated PHY (namely read_page() and write_page() in
> struct phy_driver). If DP can't be loaded (e.g. because ND is in
> initramfs but DP is not), then phylib will use the generic
> PHY driver GP. GP doesn't implement certain callbacks that are
> needed by ND, therefore ND's probe has to bail out with an error
> once it detects that DP is not loaded.
> We have this problem with driver r8169 having such a dependency
> on PHY driver realtek. Some distributions have tools for
> configuring initramfs that consider hard dependencies based on
> depmod output. Means so far somebody can add r8169.ko to initramfs,
> and neither human being nor machine will have an idea that
> realtek.ko needs to be added too.
> Attached patch set (two patches for kmod, one for the kernel)
> allows to express this hard dependency of ND from DP. depmod will
> read this dependency information and treat it like a symbol-based
> dependency. As a result tools e.g. populating initramfs can
> consider the dependency and place DP in initramfs if ND is in
> initramfs. On my system the patch set does the trick when
> adding following line to r8169_main.c:
> MODULE_HARDDEP("realtek");
> I'm interested in your opinion on the patches, and whether you
> maybe have a better idea how to solve the problem.
> Heiner
Any feedback?

Thanks, Heiner

  parent reply index

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <>
2020-04-01 21:22 ` Fwd: " Heiner Kallweit
2020-04-08 21:37 ` Heiner Kallweit [this message]
     [not found] ` <20200409000200.2qsqcbrzcztk6gmu@ldmartin-desk1>
2020-04-09 22:25   ` Heiner Kallweit
2020-04-14 16:09     ` Jessica Yu
2020-04-14 16:20       ` Heiner Kallweit
2020-04-15  9:16         ` Jessica Yu

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:

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

  git send-email \ \ \ \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

Linux-Modules Archive on

Archives are clonable:
	git clone --mirror linux-modules/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 linux-modules linux-modules/ \
	public-inbox-index linux-modules

Example config snippet for mirrors

Newsgroup available over NNTP:

AGPL code for this site: git clone