* Request for suggestion on net device re-naming/re-ordering based on DT alias
@ 2019-02-27 11:54 Harini Katakam
2019-02-27 18:40 ` Stephen Hemminger
0 siblings, 1 reply; 5+ messages in thread
From: Harini Katakam @ 2019-02-27 11:54 UTC (permalink / raw)
To: netdev, linux-kernel, Nicolas Ferre, David Miller
Cc: Michal Simek, Harini Katakam, Harini Katakam
Hi,
We've had some users requesting control over net device name order
when multiple ethernet devices are present on a system. I've tried a
few solutions to this and looked it up on forums. But I apologize if
I have missed something.
I know that the current system allocates eth<n> as per probe order
but that is obviously not stably controlled by user (tried DT
re-ordering and defer probe). One solution is to use DT alias names
to write to (net_device)->name as follows:
Devicetree:
aliases {
ethernet0 = &mac1;
ethernet1 = &mac0;
};
Driver probe:
+ /* Read ethernet DT alias id and assign to right device name*/
+ id = of_alias_get_id(np, "ethernet");
+ if (id < 0) {
+ dev_warn(&pdev->dev, "failed to get alias id (%u)\n", id);
+ return id;
+ }
+ snprintf(dev->name, sizeof(dev->name), "eth%d", id);
+
These three drivers seem to have something similar for mdio/phy bus IDs:
drivers/net/ethernet/broadcom/genet/bcmmii.c:409: id =
of_alias_get_id(dn, "eth");
drivers/net/ethernet/samsung/sxgbe/sxgbe_platform.c:43: plat->bus_id =
of_alias_get_id(np, "ethernet");
drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c:404:
plat->bus_id = of_alias_get_id(np, "ethernet");
Drawback: This approach will break if alias is not provided for one
of the interfaces on board. Not to mention, there could be systems
with multiple ethernet makes (for ex. Cadence macb and Xilinx axienet)
If one of the drivers does not have an alias read mechanism, it is
possible to have clashing ID assignments. Is there any way this
solution can be changed to be stable/acceptable?
One other alternative I've tried is netdev kernel bootargs but this
device name was not being picked by the kernel:
https://www.kernel.org/doc/html/v4.19/admin-guide/kernel-parameters.html
netdev= <mac1’s interrupt id>, <mac1’s base address>, eth0
netdev=<mac0’s interrupt id>, <mac0’s base address>, eth1
Could you please suggest any alternatives?
Thanks!
Regards,
Harini
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Request for suggestion on net device re-naming/re-ordering based on DT alias
2019-02-27 11:54 Request for suggestion on net device re-naming/re-ordering based on DT alias Harini Katakam
@ 2019-02-27 18:40 ` Stephen Hemminger
2019-02-27 18:45 ` Florian Fainelli
2019-02-28 5:43 ` Harini Katakam
0 siblings, 2 replies; 5+ messages in thread
From: Stephen Hemminger @ 2019-02-27 18:40 UTC (permalink / raw)
To: Harini Katakam
Cc: netdev, linux-kernel, Nicolas Ferre, David Miller, Michal Simek,
Harini Katakam, Harini Katakam
On Wed, 27 Feb 2019 17:24:03 +0530
Harini Katakam <harinik@xilinx.com> wrote:
> Hi,
>
> We've had some users requesting control over net device name order
> when multiple ethernet devices are present on a system. I've tried a
> few solutions to this and looked it up on forums. But I apologize if
> I have missed something.
>
> I know that the current system allocates eth<n> as per probe order
> but that is obviously not stably controlled by user (tried DT
> re-ordering and defer probe). One solution is to use DT alias names
> to write to (net_device)->name as follows:
> Devicetree:
> aliases {
> ethernet0 = &mac1;
> ethernet1 = &mac0;
> };
> Driver probe:
> + /* Read ethernet DT alias id and assign to right device name*/
> + id = of_alias_get_id(np, "ethernet");
> + if (id < 0) {
> + dev_warn(&pdev->dev, "failed to get alias id (%u)\n", id);
> + return id;
> + }
> + snprintf(dev->name, sizeof(dev->name), "eth%d", id);
> +
>
> These three drivers seem to have something similar for mdio/phy bus IDs:
> drivers/net/ethernet/broadcom/genet/bcmmii.c:409: id =
> of_alias_get_id(dn, "eth");
> drivers/net/ethernet/samsung/sxgbe/sxgbe_platform.c:43: plat->bus_id =
> of_alias_get_id(np, "ethernet");
> drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c:404:
> plat->bus_id = of_alias_get_id(np, "ethernet");
>
> Drawback: This approach will break if alias is not provided for one
> of the interfaces on board. Not to mention, there could be systems
> with multiple ethernet makes (for ex. Cadence macb and Xilinx axienet)
> If one of the drivers does not have an alias read mechanism, it is
> possible to have clashing ID assignments. Is there any way this
> solution can be changed to be stable/acceptable?
>
> One other alternative I've tried is netdev kernel bootargs but this
> device name was not being picked by the kernel:
> https://www.kernel.org/doc/html/v4.19/admin-guide/kernel-parameters.html
> netdev= <mac1’s interrupt id>, <mac1’s base address>, eth0
> netdev=<mac0’s interrupt id>, <mac0’s base address>, eth1
>
> Could you please suggest any alternatives?
> Thanks!
>
> Regards,
> Harini
Device naming is a hard problem, and there is no perfect solution.
Device tree should be providing hints to userspace policy for naming, not
trying to do it in the kernel.
See: https://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Request for suggestion on net device re-naming/re-ordering based on DT alias
2019-02-27 18:40 ` Stephen Hemminger
@ 2019-02-27 18:45 ` Florian Fainelli
2019-02-27 21:42 ` Stephen Hemminger
2019-02-28 5:43 ` Harini Katakam
1 sibling, 1 reply; 5+ messages in thread
From: Florian Fainelli @ 2019-02-27 18:45 UTC (permalink / raw)
To: Stephen Hemminger, Harini Katakam
Cc: netdev, linux-kernel, Nicolas Ferre, David Miller, Michal Simek,
Harini Katakam, Harini Katakam
On 2/27/19 10:40 AM, Stephen Hemminger wrote:
> On Wed, 27 Feb 2019 17:24:03 +0530
> Harini Katakam <harinik@xilinx.com> wrote:
>
>> Hi,
>>
>> We've had some users requesting control over net device name order
>> when multiple ethernet devices are present on a system. I've tried a
>> few solutions to this and looked it up on forums. But I apologize if
>> I have missed something.
>>
>> I know that the current system allocates eth<n> as per probe order
>> but that is obviously not stably controlled by user (tried DT
>> re-ordering and defer probe). One solution is to use DT alias names
>> to write to (net_device)->name as follows:
>> Devicetree:
>> aliases {
>> ethernet0 = &mac1;
>> ethernet1 = &mac0;
>> };
>> Driver probe:
>> + /* Read ethernet DT alias id and assign to right device name*/
>> + id = of_alias_get_id(np, "ethernet");
>> + if (id < 0) {
>> + dev_warn(&pdev->dev, "failed to get alias id (%u)\n", id);
>> + return id;
>> + }
>> + snprintf(dev->name, sizeof(dev->name), "eth%d", id);
>> +
>>
>> These three drivers seem to have something similar for mdio/phy bus IDs:
>> drivers/net/ethernet/broadcom/genet/bcmmii.c:409: id =
>> of_alias_get_id(dn, "eth");
>> drivers/net/ethernet/samsung/sxgbe/sxgbe_platform.c:43: plat->bus_id =
>> of_alias_get_id(np, "ethernet");
>> drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c:404:
>> plat->bus_id = of_alias_get_id(np, "ethernet");
>>
>> Drawback: This approach will break if alias is not provided for one
>> of the interfaces on board. Not to mention, there could be systems
>> with multiple ethernet makes (for ex. Cadence macb and Xilinx axienet)
>> If one of the drivers does not have an alias read mechanism, it is
>> possible to have clashing ID assignments. Is there any way this
>> solution can be changed to be stable/acceptable?
>>
>> One other alternative I've tried is netdev kernel bootargs but this
>> device name was not being picked by the kernel:
>> https://www.kernel.org/doc/html/v4.19/admin-guide/kernel-parameters.html
>> netdev= <mac1’s interrupt id>, <mac1’s base address>, eth0
>> netdev=<mac0’s interrupt id>, <mac0’s base address>, eth1
>>
>> Could you please suggest any alternatives?
>> Thanks!
>>
>> Regards,
>> Harini
>
> Device naming is a hard problem, and there is no perfect solution.
>
> Device tree should be providing hints to userspace policy for naming, not
> trying to do it in the kernel.
And Device Tree does already, if you look at the uevent attributes that
the kernel sends, there should be ample information to uniquely
determine which physical network device the network device maps to, e
for instance:
cat /sys/class/net/eth*/device/uevent
DRIVER=brcm-systemport
OF_NAME=ethernet
OF_FULLNAME=/rdb/ethernet@9300000
OF_TYPE=network
OF_COMPATIBLE_0=brcm,systemportlite-v1.00
OF_COMPATIBLE_1=brcm,systemport
OF_COMPATIBLE_N=2
OF_ALIAS_0=eth0
MODALIAS=of:NethernetTnetworkCbrcm,systemportlite-v1.00Cbrcm,systemport
--
Florian
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Request for suggestion on net device re-naming/re-ordering based on DT alias
2019-02-27 18:45 ` Florian Fainelli
@ 2019-02-27 21:42 ` Stephen Hemminger
0 siblings, 0 replies; 5+ messages in thread
From: Stephen Hemminger @ 2019-02-27 21:42 UTC (permalink / raw)
To: Florian Fainelli
Cc: Harini Katakam, netdev, linux-kernel, Nicolas Ferre,
David Miller, Michal Simek, Harini Katakam, Harini Katakam
On Wed, 27 Feb 2019 10:45:44 -0800
Florian Fainelli <f.fainelli@gmail.com> wrote:
> On 2/27/19 10:40 AM, Stephen Hemminger wrote:
> > On Wed, 27 Feb 2019 17:24:03 +0530
> > Harini Katakam <harinik@xilinx.com> wrote:
> >
> >> Hi,
> >>
> >> We've had some users requesting control over net device name order
> >> when multiple ethernet devices are present on a system. I've tried a
> >> few solutions to this and looked it up on forums. But I apologize if
> >> I have missed something.
> >>
> >> I know that the current system allocates eth<n> as per probe order
> >> but that is obviously not stably controlled by user (tried DT
> >> re-ordering and defer probe). One solution is to use DT alias names
> >> to write to (net_device)->name as follows:
> >> Devicetree:
> >> aliases {
> >> ethernet0 = &mac1;
> >> ethernet1 = &mac0;
> >> };
> >> Driver probe:
> >> + /* Read ethernet DT alias id and assign to right device name*/
> >> + id = of_alias_get_id(np, "ethernet");
> >> + if (id < 0) {
> >> + dev_warn(&pdev->dev, "failed to get alias id (%u)\n", id);
> >> + return id;
> >> + }
> >> + snprintf(dev->name, sizeof(dev->name), "eth%d", id);
> >> +
> >>
> >> These three drivers seem to have something similar for mdio/phy bus IDs:
> >> drivers/net/ethernet/broadcom/genet/bcmmii.c:409: id =
> >> of_alias_get_id(dn, "eth");
> >> drivers/net/ethernet/samsung/sxgbe/sxgbe_platform.c:43: plat->bus_id =
> >> of_alias_get_id(np, "ethernet");
> >> drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c:404:
> >> plat->bus_id = of_alias_get_id(np, "ethernet");
> >>
> >> Drawback: This approach will break if alias is not provided for one
> >> of the interfaces on board. Not to mention, there could be systems
> >> with multiple ethernet makes (for ex. Cadence macb and Xilinx axienet)
> >> If one of the drivers does not have an alias read mechanism, it is
> >> possible to have clashing ID assignments. Is there any way this
> >> solution can be changed to be stable/acceptable?
> >>
> >> One other alternative I've tried is netdev kernel bootargs but this
> >> device name was not being picked by the kernel:
> >> https://www.kernel.org/doc/html/v4.19/admin-guide/kernel-parameters.html
> >> netdev= <mac1’s interrupt id>, <mac1’s base address>, eth0
> >> netdev=<mac0’s interrupt id>, <mac0’s base address>, eth1
> >>
> >> Could you please suggest any alternatives?
> >> Thanks!
> >>
> >> Regards,
> >> Harini
> >
> > Device naming is a hard problem, and there is no perfect solution.
> >
> > Device tree should be providing hints to userspace policy for naming, not
> > trying to do it in the kernel.
>
> And Device Tree does already, if you look at the uevent attributes that
> the kernel sends, there should be ample information to uniquely
> determine which physical network device the network device maps to, e
> for instance:
>
> cat /sys/class/net/eth*/device/uevent
> DRIVER=brcm-systemport
> OF_NAME=ethernet
> OF_FULLNAME=/rdb/ethernet@9300000
> OF_TYPE=network
> OF_COMPATIBLE_0=brcm,systemportlite-v1.00
> OF_COMPATIBLE_1=brcm,systemport
> OF_COMPATIBLE_N=2
> OF_ALIAS_0=eth0
> MODALIAS=of:NethernetTnetworkCbrcm,systemportlite-v1.00Cbrcm,systemport
Then you need to work with udev developers to handle device tree better.
By design ethN is not used for persistent naming, only other names like ensX.
This allows for safer renaming and provides way to handle devices that may
not match any rules.
Most of udev naming is based of properties in sysfs like pci-slot, port etc.
If you had that available on these devices, it would just work now.
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Request for suggestion on net device re-naming/re-ordering based on DT alias
2019-02-27 18:40 ` Stephen Hemminger
2019-02-27 18:45 ` Florian Fainelli
@ 2019-02-28 5:43 ` Harini Katakam
1 sibling, 0 replies; 5+ messages in thread
From: Harini Katakam @ 2019-02-28 5:43 UTC (permalink / raw)
To: Stephen Hemminger
Cc: netdev, linux-kernel, Nicolas Ferre, David Miller, Michal Simek,
Harini Katakam
On Thu, Feb 28, 2019 at 12:10 AM Stephen Hemminger
<stephen@networkplumber.org> wrote:
>
> On Wed, 27 Feb 2019 17:24:03 +0530
> Harini Katakam <harinik@xilinx.com> wrote:
>
<snip>
>
> Device naming is a hard problem, and there is no perfect solution.
>
> Device tree should be providing hints to userspace policy for naming, not
> trying to do it in the kernel.
> See: https://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/
Thanks Stephen - I'll try this.
Regards,
Harini
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2019-02-28 5:43 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-02-27 11:54 Request for suggestion on net device re-naming/re-ordering based on DT alias Harini Katakam
2019-02-27 18:40 ` Stephen Hemminger
2019-02-27 18:45 ` Florian Fainelli
2019-02-27 21:42 ` Stephen Hemminger
2019-02-28 5:43 ` Harini Katakam
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).