linux-kernel - Re: drivers/net/dsa/dsa_loop

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: Tue, 14 May 2024 21:05:58 -0700
From: Florian Fainelli <f.fainelli@...il.com>
To: Andrew Lunn <andrew@...n.ch>,
 Stephen Langstaff <stephenlangstaff1@...il.com>
Cc: linux-kernel@...r.kernel.org, OlteanV@...il.com
Subject: Re: drivers/net/dsa/dsa_loop_bdinfo.c build problems



On 5/14/2024 9:17 AM, Andrew Lunn wrote:
> On Tue, May 14, 2024 at 05:08:24PM +0100, Stephen Langstaff wrote:
>> On Tue, May 14, 2024 at 1:32 PM Andrew Lunn <andrew@...n.ch> wrote:
>>
>>> So try to making FIXED_PHY = m, and load it after dsa_loop_bdinfo.ko.
>>
>> In my configuration FIXED_PHY is selected by several other modules:
>>    │ Selected by [y]:
>>    │   - FSL_DPAA_ETH [=y] && NETDEVICES [=y] && ETHERNET [=y] &&
>> NET_VENDOR_FREESCALE [=y] && FSL_DPAA [=y] && FSL_FMAN [=y]
>>    │   - FWNODE_MDIO [=y] && NETDEVICES [=y] && MDIO_DEVICE [=y] &&
>> (ACPI [=y] || OF [=y] || COMPILE_TEST [=n])
>>    │   - OF_MDIO [=y] && NETDEVICES [=y] && MDIO_DEVICE [=y] && OF [=y]
>> && PHYLIB [=y]
>>
>> ...so it looks pretty tied up with the MDIO support which I guess I
>> will need for the real PHY!
>>
>> If I sorted out building the dsa_loop_bdinfo.c code as a built-in do
>> you think that would solve the ordering issue?

I have re-created the issue with CONFIG_FIXED_PHY=y and for a reason I 
do not yet understand the following rule:

obj-$(CONFIG_FIXED_PHY)                += dsa_loop_bdinfo.o

does not result in the kernel image containing the dsa_loop_bdinfo.o 
object symbols. I am fairly sure this worked when this was submitted 
back then, so give me a day or two to figure out why. AFAICT the make 
rule is simply not executed.

> 
> Probably.
> 
> Florian test setup shows it can work.
> 
> This mdio board info stuff is based on the same concept for I2C
> devices. However, it is simplified a bit, since it is not really meant
> for production use. What i suspect the I2C version does is that when a
> new board info is registers, it walks all the existing I2C busses and
> sees if there is a match. The MDIO version is missing this, it only
> runs the match when a bus is added. So it is less forgiving of order.

Yes that is fair enough, there could be improvements in that area. Or 
nowadays, given that software node(s) are a thing and that we can apply 
overlays to PCI(e) devices, we might consider doing that and ditch 
dsa_loop_bdinfo.c entirely.
-- 
Florian