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

Philipp Puschmann p.puschmann at pironex.com
Tue Jul 2 07:25:57 PDT 2024


Hi Dragan,

> Hello Philipp,
> 
> 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?
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.

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

Regards,
Philipp

> 
>> Signed-off-by: Philipp Puschmann <p.puschmann at pironex.com>
>> ---
>>  arch/arm64/boot/dts/rockchip/rk3568.dtsi | 4 ++++
>>  arch/arm64/boot/dts/rockchip/rk356x.dtsi | 1 +
>>  2 files changed, 5 insertions(+)
>>
>> diff --git a/arch/arm64/boot/dts/rockchip/rk3568.dtsi
>> b/arch/arm64/boot/dts/rockchip/rk3568.dtsi
>> index f1be76a54ceb..42018c8666e0 100644
>> --- a/arch/arm64/boot/dts/rockchip/rk3568.dtsi
>> +++ b/arch/arm64/boot/dts/rockchip/rk3568.dtsi
>> @@ -8,6 +8,10 @@
>>  / {
>>      compatible = "rockchip,rk3568";
>>
>> +    aliases {
>> +        ethernet1 = &gmac0;
>> +    };
>> +
>>      sata0: sata at fc000000 {
>>          compatible = "rockchip,rk3568-dwc-ahci", "snps,dwc-ahci";
>>          reg = <0 0xfc000000 0 0x1000>;
>> diff --git a/arch/arm64/boot/dts/rockchip/rk356x.dtsi
>> b/arch/arm64/boot/dts/rockchip/rk356x.dtsi
>> index d8543b5557ee..e13bd7b24752 100644
>> --- a/arch/arm64/boot/dts/rockchip/rk356x.dtsi
>> +++ b/arch/arm64/boot/dts/rockchip/rk356x.dtsi
>> @@ -43,6 +43,7 @@ aliases {
>>          spi1 = &spi1;
>>          spi2 = &spi2;
>>          spi3 = &spi3;
>> +        ethernet0 = &gmac1;
>>      };
>>
>>      cpus {

-- 
Philipp Puschmann, M.Sc.
Softwareentwicklung

pironex GmbH
Stangenland 4
18146 Rostock
www.pironex.de

Tel.:   +49 (0) 381 7006 08 44
E-Mail: p.puschmann at pironex.com
Firma:  +49 (0) 381 70 06 08 0
Fax:    +49 (0) 381 49 68 02 77
Web:    http://www.pironex.de



More information about the Linux-rockchip mailing list