linux-kernel - 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]

Message-ID: <56f1d181-92a3-859e-9185-ed785ca1afa1@loongson.cn>
Date:   Mon, 6 Dec 2021 10:27:27 +0800
From:   zhuyinbo <zhuyinbo@...ngson.cn>
To:     Andrew Lunn <andrew@...n.ch>
Cc:     netdev@...r.kernel.org, linux-kernel@...r.kernel.org,
        linux-kbuild@...r.kernel.org, zhuyinbo@...ngson.cn
Subject: Re: [PATCH v2 1/2] modpost: file2alias: fixup mdio alias garbled code
 in modules.alias


在 2021/12/1 上午8:38, Andrew Lunn 写道:
>> 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

Hi Andrew, Russell King,


mdio phy device use DT that it isn't appropriate, because phy device was 
depend on mac and was set by mac use mdio.

even though, you use DT to descripte phy device and phy driver must use 
"of" type export, and in mainstrem phy driver,

most of phy driver was use "mdio",  not use DT, please you note! 
perphaps you can learn about do_of_table, and the key

point is that uevent wheter match alias configure for module auto load 
issue.

for more detailed information, please review v4 patch some explain:

[v4,1/2] modpost: file2alias: make mdio alias configure match mdio uevent.

https://patchwork.kernel.org/project/netdevbpf/patch/1638609208-10339-1-git-send-email-zhuyinbo@loongson.cn/


BRs,

Yinbo Zhu.