From: "Russell King (Oracle)" <linux@armlinux.org.uk>
To: Andrew Lunn <andrew@lunn.ch>
Cc: Heiner Kallweit <hkallweit1@gmail.com>,
Yinbo Zhu <zhuyinbo@loongson.cn>,
"David S. Miller" <davem@davemloft.net>,
Jakub Kicinski <kuba@kernel.org>,
Masahiro Yamada <masahiroy@kernel.org>,
Michal Marek <michal.lkml@markovi.net>,
Nick Desaulniers <ndesaulniers@google.com>,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-kbuild@vger.kernel.org
Subject: Re: [PATCH v2 1/2] modpost: file2alias: fixup mdio alias garbled code in modules.alias
Date: Wed, 1 Dec 2021 09:02:05 +0000 [thread overview]
Message-ID: <Yac6DakLxBxFgfZk@shell.armlinux.org.uk> (raw)
In-Reply-To: <YabEHd+Z5SPAhAT5@lunn.ch>
On Wed, Dec 01, 2021 at 01:38:53AM +0100, Andrew Lunn wrote:
> > However, this won't work for PHY devices created _before_ the kernel
> > has mounted the rootfs, whether or not they end up being used. So,
> > every PHY mentioned in DT will be created before the rootfs is mounted,
> > and none of these PHYs will have their modules loaded.
>
> Hi Russell
>
> I think what you are saying here is, if the MAC or MDIO bus driver is
> built in, the PHY driver also needs to be built in?
>
> If the MAC or MDIO bus driver is a module, it means the rootfs has
> already been mounted in order to get these modules. And so the PHY
> driver as a module will also work.
Yes, because the module loading is performed by phy_device_create() when
it calls phy_request_driver_module(), which will happen when either the
MDIO bus is scanned or the DT is parsed for the PHY nodes.
> > I believe this is the root cause of Yinbo Zhu's issue.
>
> You are speculating that in Yinbo Zhu case, the MAC driver is built
> in, the PHY is a module. The initial request for the firmware fails.
s/firmware/module/ and it could also be the MDIO bus driver that is
built in.
> Yinbo Zhu would like udev to try again later when the modules are
> available.
I think so - it's speculation because it seems quite difficult to find
out detailed information.
> > What we _could_ do is review all device trees and PHY drivers to see
> > whether DT modaliases are ever used for module loading. If they aren't,
> > then we _could_ make the modalias published by the kernel conditional
> > on the type of mdio device - continue with the DT approach for non-PHY
> > devices, and switch to the mdio: scheme for PHY devices. I repeat, this
> > can only happen if no PHY drivers match using the DT scheme, otherwise
> > making this change _will_ cause a regression.
>
> Take a look at
> drivers/net/mdio/of_mdio.c:whitelist_phys[] and the comment above it.
>
> So there are some DT blobs out there with compatible strings for
> PHYs. I've no idea if they actually load that way, or the standard PHY
> mechanism is used.
Well, this suggests we have no instances - if none of our modules
contain a DT table to match a PHY-driver, then we should be pretty
safe.
$ grep phy_driver drivers/net -rl | xargs grep 'MODULE_ALIAS\|MODULE_DEVICE.*of'
drivers/net/phy/xilinx_gmii2rgmii.c:MODULE_DEVICE_TABLE(of, xgmiitorgmii_of_match);
drivers/net/mdio/mdio-moxart.c:MODULE_DEVICE_TABLE(of, moxart_mdio_dt_ids);
drivers/net/dsa/mt7530.c:MODULE_DEVICE_TABLE(of, mt7530_of_match);
All three look to be false hits - none are phy drivers themselves, they
just reference "phy_driver". So, I think we can say that we have no
instances of PHY driver being matched using DT in net-next in
drivers/net. Hopefully, there aren't any PHY drivers elsewhere in the
kernel tree.
That is not true universally for all MDIO though - as
xilinx_gmii2rgmii.c clearly shows. That is a MDIO driver which uses DT
the compatible string to do the module load. So, we have proof there
that Yinbo Zhu's change will definitely cause a regression which we
can not allow.
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!
next prev parent reply other threads:[~2021-12-01 9:02 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-11-26 9:45 [PATCH v2 1/2] modpost: file2alias: fixup mdio alias garbled code in modules.alias Yinbo Zhu
2021-11-26 9:45 ` [PATCH v2 2/2] net: mdio: fixup ethernet phy module auto-load function Yinbo Zhu
2021-11-26 10:13 ` Russell King (Oracle)
2021-11-26 10:21 ` [PATCH v2 1/2] modpost: file2alias: fixup mdio alias garbled code in modules.alias Heiner Kallweit
2021-11-30 8:45 ` zhuyinbo
2021-11-30 11:46 ` Russell King (Oracle)
2021-12-01 0:38 ` Andrew Lunn
2021-12-01 9:02 ` Russell King (Oracle) [this message]
2021-12-06 2:27 ` zhuyinbo
2021-12-07 9:41 ` zhuyinbo
2021-12-07 11:18 ` Russell King (Oracle)
2022-01-04 13:11 ` zhuyinbo
2022-01-04 13:25 ` Russell King (Oracle)
2022-01-05 3:33 ` zhuyinbo
2022-01-05 9:42 ` Russell King (Oracle)
2022-01-06 3:56 ` zhuyinbo
2022-01-06 12:46 ` 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=Yac6DakLxBxFgfZk@shell.armlinux.org.uk \
--to=linux@armlinux.org.uk \
--cc=andrew@lunn.ch \
--cc=davem@davemloft.net \
--cc=hkallweit1@gmail.com \
--cc=kuba@kernel.org \
--cc=linux-kbuild@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=masahiroy@kernel.org \
--cc=michal.lkml@markovi.net \
--cc=ndesaulniers@google.com \
--cc=netdev@vger.kernel.org \
--cc=zhuyinbo@loongson.cn \
/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).