| Message ID | 20240702124626.116290-1-p.puschmann@pironex.com (mailing list archive) |
|---|---|
| State | New |
| Headers | show |
| Series | arm64: dts: rockchip: rk356x: add ethernet aliases | expand |
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. The sysfs issue that you've discovered should be instead solved in some other, more systemic way. > Signed-off-by: Philipp Puschmann <p.puschmann@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@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 {
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@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@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 {
On 02/07/2024 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. > > Signed-off-by: Philipp Puschmann <p.puschmann@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; Nope, sorry. SoC does not have working Ethernet. Best regards, Krzysztof
On 02/07/2024 16:25, Philipp Puschmann wrote: > 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? I think this was explained many times. Did you look at above discussions? Best regards, Krzysztof
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. >> 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? >>> Signed-off-by: Philipp Puschmann <p.puschmann@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@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 {
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
On 2024-07-02 17:14, Philipp Puschmann wrote: > 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. Sure, ethernetX aliases are optional. Basically, if a board exposes none of the Ethernet interfaces built into the SoC, there should be no ethernetX aliases and, of course, no GMACs enabled in the board dts file. >>>> 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. Frankly, I'm not sure that defining aliases is some hidden magic, :) but I think that I understand your point. Thus, I'd still suggest that you try to improve the code in the areas you found troublesome, making it more robust in a systemic way.
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@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 {
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. Signed-off-by: Philipp Puschmann <p.puschmann@pironex.com> --- arch/arm64/boot/dts/rockchip/rk3568.dtsi | 4 ++++ arch/arm64/boot/dts/rockchip/rk356x.dtsi | 1 + 2 files changed, 5 insertions(+)