[PATCH] arm64: dts: rockchip: rk356x: add ethernet aliases

[Philipp Puschmann]

Am 02.07.24 um 16:41 schrieb Dragan Simic:
> On 2024-07-02 16:25, Philipp Puschmann wrote:
>>> On 2024-07-02 14:46, Philipp Puschmann wrote:
>>>> Providing ethernet aliases solves a subtle problem for the rk3568. The
>>>> bus_id used for the sysfs directory name of the mdio. Without ethernet
>>>> alias the bus_id is always 0 and so creating the sysfs directory for the
>>>> second mdio fails with a duplicate filename error and by this the setup
>>>> of the second ethernet port fails too.
>>>>
>>>> Note: The alias numbering is inverted as gmac1 comes from more generic
>>>> rk356x.dtsi but gmac0 comes from specialised rk3568.
>>>
>>> Please see the following commits and the discussions on the rockchip-linux
>>> mailing list that are linked in them:
>>>
>>> - b0140a1b3b1d ("arm64: dts: rockchip: Add ethernet0 alias to the dts
>>>   for RK3588(S) boards")
>>> - 36d9b3ae708e ("arm64: dts: rockchip: Add ethernet0 alias to the dts
>>>   for RK3566 boards")
>>> - 5d90cb1edcf7 ("arm64: dts: rockchip: Remove ethernet0 alias from the
>>>   SoC dtsi for RK3399")
>>> - c900fef5deff ("arm64: dts: rockchip: Remove ethernet0 alias from the
>>>   SoC dtsi for RK3368")
>>>> To sum it up, ethernetX aliases are considered board-level features,
>>> because not all boards/devices actually expose the Ethernet interfaces
>>> built into the SoCs.  Thus, adding ethernetX aliases to the SoC dtsi
>>> files, unfortunately, isn't an acceptable option.
>>
>> Are ethernet aliases are handled differently than i2c, serial and spi aliases?
>> There are aliases for each of them, without doing any harm. And even if the gmac
>> nodes are disabled with status property?
> 
> In a word, yes; they are handled a bit differently, which I already tried
> to sum up.  As Krzysztof already noted, please read the discussions linked
> in the patches listed above.
> 
>> On my rk3568-based custom board i had no ethernet aliases and networking was
>> enabled normally with the status properties of the gmac nodes. Either one or
>> the other or both network devices were initialized. Would be strange if an
>> alias would be used without regard to initializing a device driver.
> 
> It's also about following the TRMs and the aliases (or common names) defined
> in them, as described in the above-mentioned discussions.
Ok. I understand the point why the ethernet alias belongs to the board dts instead
of the SoC dtis.
But on the quick i found no reference in Documentation/ or in drivers/net or the
mentioned
that and why ethernet aliases aren't optional (and it appears in many cases they
are). From my years of board bring-up my understanding of aliases was, that they
are in general are optional and for some subsystems they are used to hard-code
sysfs paths and device names in /dev to solve the problem of randomness in
initialization order.
> 
>>> The sysfs issue that you've discovered should be instead solved in some
>>> other, more systemic way.
>>
>> The bus_id value comes from stmmac_platform.c and of_alias_get_id() with
>> "ethernet" as parameter is used, what is a common way in the kernel. It
>> delivers unique ints starting with 0. stmmac_mdio then uses the bus_id to
>> create a mdio bus id string stmmac-${bus_id} to register a mdio_bus.
>> From my understanding this kind of bus id is commonly used to name devices
>> and paths in the sysfs. Viewed only this problem it would be possible
>> to use other information like the node address or some unique
>> information to use it as unique part of the mdio bus id. But doesn't break
>> things too, at least some kind of convention?
>>
>> Another hack i tried first, was to use a static increasing int to get
>> the bus_id. This would keep the resulting sysfs tree probably unchanged
>> but would drop the connection between dts and bus numbering in sysfs.
> 
> Wouldn't those issues be solved by simply defining the needed ethernetX
> aliases in the dts file for your board?

Yes. But for me it wasn't obviously that and why i would need that aliases
to make a mdio work that is not even mentioned in the dts file (in my case).
So in a perfect would would like to have a solution that comes without some
hidden magic or the need to dig through the code.

Regards,
Philipp