From: Niklas Cassel <cassel@kernel.org>
To: Andrew Lunn <andrew@lunn.ch>
Cc: "Russell King (Oracle)" <linux@armlinux.org.uk>,
Francesco Valla <francesco@valla.it>,
Andrew Lunn <andrew+netdev@lunn.ch>,
Heiner Kallweit <hkallweit1@gmail.com>,
netdev@vger.kernel.org, Anand Moon <linux.amoon@gmail.com>,
Luis Chamberlain <mcgrof@kernel.org>
Subject: Re: [PATCH] net: phy: don't issue a module request if a driver is available
Date: Fri, 3 Jan 2025 15:34:26 +0100 [thread overview]
Message-ID: <Z3f1coRBcuKd1Eao@ryzen> (raw)
In-Reply-To: <cff14918-0143-4309-9317-675c18ad3a8f@lunn.ch>
On Fri, Jan 03, 2025 at 03:12:14PM +0100, Andrew Lunn wrote:
> > FWIW, the patch in $subject does make the splat go away for me.
> > (I have the PHY driver built as built-in).
> >
> > The patch in $subject does "Add a list of registered drivers and check
> > if one is already available before resorting to call request_module();
> > in this way, if the PHY driver is already there, the MDIO bus can perform
> > the async probe."
>
> Lets take a step backwards.
>
> How in general should module loading work with async probe? Lets
> understand that first.
>
> Then we can think about what is special about PHYs, and how we can fit
> into the existing framework.
I agree that it might be a good idea, if possible, for request_module()
itself to see if the requested module is already registered, and then do
nothing.
Adding Luis (modules maintainer) to CC.
Luis, phylib calls request_module() unconditionally, regardless if there
is a driver registered already (phy driver built as built-in).
This causes the splat described here to be printed:
https://lore.kernel.org/netdev/7103704.9J7NaK4W3v@fedora.fritz.box/T/#u
But as far as I can tell, this is a false positive, since the call cannot
possibly load any module (since the driver is built as built-in and not
as a module).
Kind regards,
Niklas
next prev parent reply other threads:[~2025-01-03 14:34 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-01-01 23:51 [PATCH] net: phy: don't issue a module request if a driver is available Francesco Valla
2025-01-02 9:35 ` [EXTERNAL] " Suman Ghosh
2025-01-02 10:21 ` Francesco Valla
2025-01-03 7:47 ` Suman Ghosh
2025-01-02 11:06 ` Russell King (Oracle)
2025-01-02 13:26 ` Francesco Valla
2025-01-02 13:52 ` Andrew Lunn
2025-01-02 14:01 ` Francesco Valla
2025-01-02 14:21 ` Andrew Lunn
2025-01-03 18:00 ` Francesco Valla
2025-01-03 11:25 ` Niklas Cassel
2025-01-03 12:08 ` Russell King (Oracle)
2025-01-03 12:49 ` Niklas Cassel
2025-01-03 14:03 ` Russell King (Oracle)
2025-01-03 14:12 ` Andrew Lunn
2025-01-03 14:34 ` Niklas Cassel [this message]
2025-01-03 15:37 ` Andrew Lunn
2025-01-03 17:57 ` Francesco Valla
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=Z3f1coRBcuKd1Eao@ryzen \
--to=cassel@kernel.org \
--cc=andrew+netdev@lunn.ch \
--cc=andrew@lunn.ch \
--cc=francesco@valla.it \
--cc=hkallweit1@gmail.com \
--cc=linux.amoon@gmail.com \
--cc=linux@armlinux.org.uk \
--cc=mcgrof@kernel.org \
--cc=netdev@vger.kernel.org \
/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).