netdev - Re: [PATCH v2 1/2] modpost: file2alias: fixup mdio alias garbled code in modules.alias

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Wed, 1 Dec 2021 01:38:53 +0100
From:   Andrew Lunn <andrew@...n.ch>
To:     "Russell King (Oracle)" <linux@...linux.org.uk>
Cc:     Heiner Kallweit <hkallweit1@...il.com>,
        Yinbo Zhu <zhuyinbo@...ngson.cn>,
        "David S. Miller" <davem@...emloft.net>,
        Jakub Kicinski <kuba@...nel.org>,
        Masahiro Yamada <masahiroy@...nel.org>,
        Michal Marek <michal.lkml@...kovi.net>,
        Nick Desaulniers <ndesaulniers@...gle.com>,
        netdev@...r.kernel.org, linux-kernel@...r.kernel.org,
        linux-kbuild@...r.kernel.org
Subject: Re: [PATCH v2 1/2] modpost: file2alias: fixup mdio alias garbled
 code in modules.alias

> 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.

> 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.
Yinbo Zhu would like udev to try again later when the modules are
available.

> 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.

	Andrew