netdev - Re: drivers/of/of_mdio.c needs a small modification

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: <79bcab16-5802-c075-1615-06c64078b6c9@arf.net.pl>
Date:   Sat, 29 Aug 2020 20:01:35 +0200
From:   Adam Rudziński <adam.rudzinski@....net.pl>
To:     Andrew Lunn <andrew@...n.ch>
Cc:     Florian Fainelli <f.fainelli@...il.com>,
        netdev <netdev@...r.kernel.org>, robh+dt@...nel.org,
        frowand.list@...il.com
Subject: Re: drivers/of/of_mdio.c needs a small modification

W dniu 2020-08-29 o 18:00, Andrew Lunn pisze:
>> This is true assuming that the PHYs are always and forever connected to one
>> specific MDIO bus. This is probably reasonable. Although, in i.MX the MDIO
>> bus of FEC1 and FEC2 shares the pins.
> In general, they do not. In fact, i don't see how that can work. The
> FEC drive provides no mutual exclusion between MDIO operations on
> different MDIO controllers.
> (...)
> You have to decide which gets to control the bus, and the other
> controller is isolated.

Yes, true, but that was not what I meant. In i.MX6ULL MDIO buses of both 
FECs share the same pins, but of course only one can be active. It makes 
no sense to try to use both MDIO buses if the PHYs are connected to the 
same wires. I agree, the current state is good from this point of view.

I meant that with the split description of the mdio node the mdio bus 
for use in the system would be selected almost automatically. Suppose 
that I can do the device tree "my way":
&fec2 {
...
     mdio { phy2 ... };
...
};
&fec1 {
...
     mdio { phy1 ... };
...
};
This emphasizes which PHY is intended for use by which FEC, that's why 
it looks more natural for me.
Here, at least the FEC driver will automatically use MDIO bus from FEC2 
for all the PHYs.

Now suppose that I want to have a cheaper version, with only one 
Ethernet interface on board:
//&fec2 {
//...
//    mdio { phy2 ... };
//...
//};
&fec1 {
...
     mdio { phy1 ... };
...
};
Now, the system will use MDIO bus from FEC1.

This is just less playing with the device tree. But I agree, that you 
don't do that frequently, so that doesn't save much effort.
And, what this example doesn't show, is that the pin assignment has to 
be modfied - mdio pins have to get to fec1 now.

This way of building the device tree results from my proposition, but it 
was not my motivation.

Maybe it would be more useful if the device tree would be preprocessed 
and then compiled based on some conditions:

#if defined(CONFIG_USE_FEC2)
&fec2 {
...
     mdio { phy2 ... };
...
};
#endif
#if defined(CONFIG_USE_FEC1)
&fec1 {
...
     mdio { phy1 ... };
...
};
#endif

Best regards,
Adam