diff mbox series

[net-next,v1,4/4] usbnet: add support for label from device tree

Message ID 20220127104905.899341-5-o.rempel@pengutronix.de
State New
Headers show
Series None | expand

Commit Message

Oleksij Rempel Jan. 27, 2022, 10:49 a.m. UTC
Similar to the option to set a netdev name in device tree for switch
ports by using the property "label" in the DSA framework, this patch
adds this functionality to the usbnet infrastructure.

This will help to name the interfaces properly throughout supported
devices. This provides stable interface names which are useful
especially in embedded use cases.

Signed-off-by: Oleksij Rempel <o.rempel@pengutronix.de>
---
 drivers/net/usb/usbnet.c | 15 +++++++++++++++
 1 file changed, 15 insertions(+)

Comments

Oleksij Rempel Jan. 27, 2022, 11:23 a.m. UTC | #1
On Thu, Jan 27, 2022 at 11:57:26AM +0100, Greg KH wrote:
> On Thu, Jan 27, 2022 at 11:49:05AM +0100, Oleksij Rempel wrote:
> > Similar to the option to set a netdev name in device tree for switch
> > ports by using the property "label" in the DSA framework, this patch
> > adds this functionality to the usbnet infrastructure.
> > 
> > This will help to name the interfaces properly throughout supported
> > devices. This provides stable interface names which are useful
> > especially in embedded use cases.
> 
> Stable interface names are for userspace to set, not the kernel.
> 
> Why would USB care about this?  If you need something like this, get it
> from the USB device itself, not DT, which should have nothing to do with
> USB as USB is a dynamic, self-describing, bus.  Unlike DT.
> 
> So I do not think this is a good idea.

This is needed for embedded devices with integrated USB Ethernet
controller. Currently I have following use cases to solve:
- Board with one or multiple USB Ethernet controllers with external PHY.
  The PHY need devicetree to describe IRQ, clock sources, label on board, etc.
- Board with USB Ethernet controller with DSA switch. The USB ethernet
  controller is attached to the CPU port of DSA switch. In this case,
  DSA switch is the sub-node of the USB device. The CPU port should have
  stable name for all device related to this product.

Using user space tools to name interfaces would double the maintenance
of similar information: DT - describing the HW + udev scripts describing
same HW again.

Regards,
Oleksij
Greg KH Jan. 27, 2022, 1:21 p.m. UTC | #2
On Thu, Jan 27, 2022 at 01:00:39PM +0100, Oleksij Rempel wrote:
> On Thu, Jan 27, 2022 at 12:30:20PM +0100, Greg KH wrote:
> > On Thu, Jan 27, 2022 at 12:23:05PM +0100, Oleksij Rempel wrote:
> > > On Thu, Jan 27, 2022 at 11:57:26AM +0100, Greg KH wrote:
> > > > On Thu, Jan 27, 2022 at 11:49:05AM +0100, Oleksij Rempel wrote:
> > > > > Similar to the option to set a netdev name in device tree for switch
> > > > > ports by using the property "label" in the DSA framework, this patch
> > > > > adds this functionality to the usbnet infrastructure.
> > > > > 
> > > > > This will help to name the interfaces properly throughout supported
> > > > > devices. This provides stable interface names which are useful
> > > > > especially in embedded use cases.
> > > > 
> > > > Stable interface names are for userspace to set, not the kernel.
> > > > 
> > > > Why would USB care about this?  If you need something like this, get it
> > > > from the USB device itself, not DT, which should have nothing to do with
> > > > USB as USB is a dynamic, self-describing, bus.  Unlike DT.
> > > > 
> > > > So I do not think this is a good idea.
> > > 
> > > This is needed for embedded devices with integrated USB Ethernet
> > > controller. Currently I have following use cases to solve:
> > > - Board with one or multiple USB Ethernet controllers with external PHY.
> > >   The PHY need devicetree to describe IRQ, clock sources, label on board, etc.
> > 
> > The phy is for the USB controller, not the Ethernet controller, right?
> > If for the ethernet controller, ugh, that's a crazy design and I would
> > argue a broken one.  But whatever, DT should not be used to describe a
> > USB device itself.
> > 
> > > - Board with USB Ethernet controller with DSA switch. The USB ethernet
> > >   controller is attached to the CPU port of DSA switch. In this case,
> > >   DSA switch is the sub-node of the USB device.
> > 
> > What do you mean exactly by "sub node"?  USB does not have such a term.
> 
> Here are some examples:
> 
>   - |
>     usb@11270000 {
>         reg = <0x11270000 0x1000>;

How can a USB device have a register?

And what does 11270000 mean?


>         #address-cells = <1>;
>         #size-cells = <0>;
> 
>         ethernet@1 {
>             compatible = "usb424,ec00";
>             reg = <1>;
>             label = "LAN0";

Where did that come from?  That should be added in userspace, not from
the kernel.

> 	    // there is no internal eeprom, so MAC address is taken from
> 	    // NVMEM of the SoC.
>             local-mac-address = [00 00 00 00 00 00];
> 
>             mdio {
> 		ethernet-phy@4 {
> 			reg = <4>;
> 			// Interrupt is attached to the SoC or the GPIO
> 			// controller of the same USB devices.
> 			interrupts-extended = <&gpio1 28 IRQ_TYPE_LEVEL_LOW>;
> 			// same about reset. It is attached to the SoC
> 			// or GPIO controller of the USB device.
> 			reset-gpios = <&gpio3 31 GPIO_ACTIVE_LOW>;
> 			reset-assert-us = <10000>;
> 			reset-deassert-us = <1000>;
> 			// some external clock provider
> 			clocks = <&clk>
> 			qca,smarteee-tw-us-1g = <24>;
> 			qca,clk-out-frequency = <125000000>;

So this device does not follow the spec for this driver in that you have
to get the values for the phy from DT and not the device itself?  Why
not fix the firmware in the device to report this?

Anyway, this feels really wrong, USB should not be involved in DT by
virtue of how the bus was designed.

And again, pick your names in userspace, embedded is not "special" here.
You can do persistant network device names in a very trivial shell
script if needed, we used to do it that way 18 years ago :)

thanks,

greg k-h
Lucas Stach Jan. 27, 2022, 2:01 p.m. UTC | #3
Hi Greg,

Am Donnerstag, dem 27.01.2022 um 14:21 +0100 schrieb Greg KH:
> On Thu, Jan 27, 2022 at 01:00:39PM +0100, Oleksij Rempel wrote:
> > On Thu, Jan 27, 2022 at 12:30:20PM +0100, Greg KH wrote:
> > > On Thu, Jan 27, 2022 at 12:23:05PM +0100, Oleksij Rempel wrote:
> > > > On Thu, Jan 27, 2022 at 11:57:26AM +0100, Greg KH wrote:
> > > > > On Thu, Jan 27, 2022 at 11:49:05AM +0100, Oleksij Rempel wrote:
> > > > > > Similar to the option to set a netdev name in device tree for switch
> > > > > > ports by using the property "label" in the DSA framework, this patch
> > > > > > adds this functionality to the usbnet infrastructure.
> > > > > > 
> > > > > > This will help to name the interfaces properly throughout supported
> > > > > > devices. This provides stable interface names which are useful
> > > > > > especially in embedded use cases.
> > > > > 
> > > > > Stable interface names are for userspace to set, not the kernel.
> > > > > 
> > > > > Why would USB care about this?  If you need something like this, get it
> > > > > from the USB device itself, not DT, which should have nothing to do with
> > > > > USB as USB is a dynamic, self-describing, bus.  Unlike DT.
> > > > > 
> > > > > So I do not think this is a good idea.
> > > > 
> > > > This is needed for embedded devices with integrated USB Ethernet
> > > > controller. Currently I have following use cases to solve:
> > > > - Board with one or multiple USB Ethernet controllers with external PHY.
> > > >   The PHY need devicetree to describe IRQ, clock sources, label on board, etc.
> > > 
> > > The phy is for the USB controller, not the Ethernet controller, right?
> > > If for the ethernet controller, ugh, that's a crazy design and I would
> > > argue a broken one.  But whatever, DT should not be used to describe a
> > > USB device itself.
> > > 
> > > > - Board with USB Ethernet controller with DSA switch. The USB ethernet
> > > >   controller is attached to the CPU port of DSA switch. In this case,
> > > >   DSA switch is the sub-node of the USB device.
> > > 
> > > What do you mean exactly by "sub node"?  USB does not have such a term.
> > 
> > Here are some examples:
> > 
> >   - |
> >     usb@11270000 {
> >         reg = <0x11270000 0x1000>;
> 
> How can a USB device have a register?
> 
> And what does 11270000 mean?
> 
> 
> >         #address-cells = <1>;
> >         #size-cells = <0>;
> > 
> >         ethernet@1 {
> >             compatible = "usb424,ec00";
> >             reg = <1>;
> >             label = "LAN0";
> 
> Where did that come from?  That should be added in userspace, not from
> the kernel.
> 
> > 	    // there is no internal eeprom, so MAC address is taken from
> > 	    // NVMEM of the SoC.
> >             local-mac-address = [00 00 00 00 00 00];
> > 
> >             mdio {
> > 		ethernet-phy@4 {
> > 			reg = <4>;
> > 			// Interrupt is attached to the SoC or the GPIO
> > 			// controller of the same USB devices.
> > 			interrupts-extended = <&gpio1 28 IRQ_TYPE_LEVEL_LOW>;
> > 			// same about reset. It is attached to the SoC
> > 			// or GPIO controller of the USB device.
> > 			reset-gpios = <&gpio3 31 GPIO_ACTIVE_LOW>;
> > 			reset-assert-us = <10000>;
> > 			reset-deassert-us = <1000>;
> > 			// some external clock provider
> > 			clocks = <&clk>
> > 			qca,smarteee-tw-us-1g = <24>;
> > 			qca,clk-out-frequency = <125000000>;
> 
> So this device does not follow the spec for this driver in that you have
> to get the values for the phy from DT and not the device itself?  Why
> not fix the firmware in the device to report this?
> 
> Anyway, this feels really wrong, USB should not be involved in DT by
> virtue of how the bus was designed.

While one can argue about the kind of information provided here, it is
well defined how DT can augment the information about a device on a
runtime discoverable bus like USB. There is even a DT binding that
lists you as the maintainer of this standard:
Documentation/devicetree/bindings/usb/usb-device.yaml

USB is not special here, PCI has the same way for DT to augment runtime
discovered device information and that is even covered by the ancient
IEEE 1275 Open Firmware standard.

Regards,
Lucas
Andrew Lunn Jan. 27, 2022, 2:28 p.m. UTC | #4
> - Board with USB Ethernet controller with DSA switch. The USB ethernet
>   controller is attached to the CPU port of DSA switch. In this case,
>   DSA switch is the sub-node of the USB device. The CPU port should have
>   stable name for all device related to this product.

All that DSA requires is a phandle pointing to the MAC. It does not
care what the interface name is. It should not be an issue if udev
changes the name to something your product marketing guys say it
should be.

   Andrew
Sergey Ryazanov Feb. 3, 2022, 12:12 a.m. UTC | #5
Hello,

On Fri, Jan 28, 2022 at 5:57 AM Lucas Stach <l.stach@pengutronix.de> wrote:
> Am Donnerstag, dem 27.01.2022 um 14:21 +0100 schrieb Greg KH:
>> On Thu, Jan 27, 2022 at 01:00:39PM +0100, Oleksij Rempel wrote:
>>> On Thu, Jan 27, 2022 at 12:30:20PM +0100, Greg KH wrote:
>>>> On Thu, Jan 27, 2022 at 12:23:05PM +0100, Oleksij Rempel wrote:
>>>>> On Thu, Jan 27, 2022 at 11:57:26AM +0100, Greg KH wrote:
>>>>>> On Thu, Jan 27, 2022 at 11:49:05AM +0100, Oleksij Rempel wrote:
>>>>>>> Similar to the option to set a netdev name in device tree for switch
>>>>>>> ports by using the property "label" in the DSA framework, this patch
>>>>>>> adds this functionality to the usbnet infrastructure.
>>>>>>>
>>>>>>> This will help to name the interfaces properly throughout supported
>>>>>>> devices. This provides stable interface names which are useful
>>>>>>> especially in embedded use cases.
>>>>>>
>>>>>> Stable interface names are for userspace to set, not the kernel.
>>>>>>
>>>>>> Why would USB care about this?  If you need something like this, get it
>>>>>> from the USB device itself, not DT, which should have nothing to do with
>>>>>> USB as USB is a dynamic, self-describing, bus.  Unlike DT.
>>>>>>
>>>>>> So I do not think this is a good idea.
>>>>>
>>>>> This is needed for embedded devices with integrated USB Ethernet
>>>>> controller. Currently I have following use cases to solve:
>>>>> - Board with one or multiple USB Ethernet controllers with external PHY.
>>>>>   The PHY need devicetree to describe IRQ, clock sources, label on board, etc.
>>>>
>>>> The phy is for the USB controller, not the Ethernet controller, right?
>>>> If for the ethernet controller, ugh, that's a crazy design and I would
>>>> argue a broken one.  But whatever, DT should not be used to describe a
>>>> USB device itself.
>>>>
>>>>> - Board with USB Ethernet controller with DSA switch. The USB ethernet
>>>>>   controller is attached to the CPU port of DSA switch. In this case,
>>>>>   DSA switch is the sub-node of the USB device.
>>>>
>>>> What do you mean exactly by "sub node"?  USB does not have such a term.
>>>
>>> Here are some examples:
>>>
>>>   - |
>>>     usb@11270000 {
>>>         reg = <0x11270000 0x1000>;
>>
>> How can a USB device have a register?
>>
>> And what does 11270000 mean?
>>
>>
>>>         #address-cells = <1>;
>>>         #size-cells = <0>;
>>>
>>>         ethernet@1 {
>>>             compatible = "usb424,ec00";
>>>             reg = <1>;
>>>             label = "LAN0";
>>
>> Where did that come from?  That should be added in userspace, not from
>> the kernel.
>>
>>>         // there is no internal eeprom, so MAC address is taken from
>>>         // NVMEM of the SoC.
>>>             local-mac-address = [00 00 00 00 00 00];
>>>
>>>             mdio {
>>>             ethernet-phy@4 {
>>>                     reg = <4>;
>>>                     // Interrupt is attached to the SoC or the GPIO
>>>                     // controller of the same USB devices.
>>>                     interrupts-extended = <&gpio1 28 IRQ_TYPE_LEVEL_LOW>;
>>>                     // same about reset. It is attached to the SoC
>>>                     // or GPIO controller of the USB device.
>>>                     reset-gpios = <&gpio3 31 GPIO_ACTIVE_LOW>;
>>>                     reset-assert-us = <10000>;
>>>                     reset-deassert-us = <1000>;
>>>                     // some external clock provider
>>>                     clocks = <&clk>
>>>                     qca,smarteee-tw-us-1g = <24>;
>>>                     qca,clk-out-frequency = <125000000>;
>>
>> So this device does not follow the spec for this driver in that you have
>> to get the values for the phy from DT and not the device itself?  Why
>> not fix the firmware in the device to report this?
>>
>> Anyway, this feels really wrong, USB should not be involved in DT by
>> virtue of how the bus was designed.
>
> While one can argue about the kind of information provided here, it is
> well defined how DT can augment the information about a device on a
> runtime discoverable bus like USB. There is even a DT binding that
> lists you as the maintainer of this standard:
> Documentation/devicetree/bindings/usb/usb-device.yaml
>
> USB is not special here, PCI has the same way for DT to augment runtime
> discovered device information and that is even covered by the ancient
> IEEE 1275 Open Firmware standard.

Not to defend this particular patch, but to talk about USB in general.

USB is not stable at all in terms of the run-time device number, but
USB is perfectly stable in terms of connection ports. If you traverse
from a host controller through a sequence of connection ports then you
reach the same device. As for PCI or any other bus. The document
referenced by Lucas shows this.

Moreover, USB specification even allows you to mark a device connected
to a particular hub port as non-detachable. What means that such a
device will be just a block on a PCB. And in this case, FDT becomes a
good (only?) option to store a subordinated device configuration.
E.g. as in Oleksij's example with a DSA switch that is connected to an
Ethernet MAC controller with the USB interface.
diff mbox series

Patch

diff --git a/drivers/net/usb/usbnet.c b/drivers/net/usb/usbnet.c
index 9a6450f796dc..3fdca0cfda88 100644
--- a/drivers/net/usb/usbnet.c
+++ b/drivers/net/usb/usbnet.c
@@ -33,6 +33,7 @@ 
 #include <linux/slab.h>
 #include <linux/kernel.h>
 #include <linux/pm_runtime.h>
+#include <linux/of.h>
 
 /*-------------------------------------------------------------------------*/
 
@@ -1762,6 +1763,20 @@  usbnet_probe (struct usb_interface *udev, const struct usb_device_id *prod)
 		if ((dev->driver_info->flags & FLAG_WWAN) != 0)
 			strscpy(net->name, "wwan%d", sizeof(net->name));
 
+		if (IS_ENABLED(CONFIG_OF)) {
+			const char *label = NULL;
+
+			/* try reading label from device tree node */
+			if (xdev->dev.of_node)
+				label = of_get_property(xdev->dev.of_node,
+							"label", NULL);
+			if (label) {
+				strscpy(net->name, label, sizeof(net->name));
+				dev_info(&udev->dev, "netdev name from dt: %s\n",
+					 net->name);
+			}
+		}
+
 		/* devices that cannot do ARP */
 		if ((dev->driver_info->flags & FLAG_NOARP) != 0)
 			net->flags |= IFF_NOARP;