mbox series

[net-next,v1,0/4] usbnet: add "label" support

Message ID 20220127104905.899341-1-o.rempel@pengutronix.de (mailing list archive)
Headers show
Series usbnet: add "label" support | expand

Message

Oleksij Rempel Jan. 27, 2022, 10:49 a.m. UTC
Add devicetree label property for usbnet devices and related yaml
schema.

Oleksij Rempel (4):
  dt-bindings: net: add schema for ASIX USB Ethernet controllers
  dt-bindings: net: add schema for Microchip/SMSC LAN95xx USB Ethernet
    controllers
  dt-bindings: net: add "label" property for all usbnet Ethernet
    controllers
  usbnet: add support for label from device tree

 .../devicetree/bindings/net/asix,ax88178.yaml | 102 ++++++++++++++++++
 .../bindings/net/microchip,lan95xx.yaml       |  84 +++++++++++++++
 .../devicetree/bindings/net/usbnet.yaml       |  36 +++++++
 drivers/net/usb/usbnet.c                      |  15 +++
 4 files changed, 237 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/net/asix,ax88178.yaml
 create mode 100644 Documentation/devicetree/bindings/net/microchip,lan95xx.yaml
 create mode 100644 Documentation/devicetree/bindings/net/usbnet.yaml

Comments

Greg KH Jan. 27, 2022, 10:57 a.m. UTC | #1
On Thu, Jan 27, 2022 at 11:49:01AM +0100, Oleksij Rempel wrote:
> Add devicetree label property for usbnet devices and related yaml
> schema.

That says _what_ you are doing, but not _why_ you would want to do such
a crazy thing, nor what problem you are attempting to solve here.

thanks,

greg k-h
Oliver Neukum Feb. 3, 2022, 9:34 a.m. UTC | #2
On 27.01.22 11:57, Greg KH wrote:
> On Thu, Jan 27, 2022 at 11:49:01AM +0100, Oleksij Rempel wrote:
>> Add devicetree label property for usbnet devices and related yaml
>> schema.
> That says _what_ you are doing, but not _why_ you would want to do such
> a crazy thing, nor what problem you are attempting to solve here.

Hi,

could you at least describe what kind of systems we are talking
about? Is this for a limited set of embedded devices?
Are we talking about devices embedded on a motherboard,
which happen to be connected by USB?

That is, are we talking about another kind of firmware
we are to take information about devices from?
And if so, why are you proposing to solve this on the
USB driver level?
It looks to me like those devices are addressed by
their USB path. But still there is no reason that a USB
driver should actively interpret firmware stuff that
comes from a source that tells us nothing about USB
properties.
In other words it looks to me like you are trying to put
a generic facility for getting device properties into
a specific driver. The question whether device names
should be read out of firmware is not a USB question.

I would suggest you implement a generic facility
in the network layer and if everybody is happy with that
obviously usbnet can pass through a pointer for that
to operate on. Frankly, it looks to me like you are
implementing only a subset of what device tree
could contain for your specific use case.

    Regards
        Oliver
Oleksij Rempel Feb. 3, 2022, 10:27 a.m. UTC | #3
On Thu, Feb 03, 2022 at 10:34:25AM +0100, Oliver Neukum wrote:
> 
> On 27.01.22 11:57, Greg KH wrote:
> > On Thu, Jan 27, 2022 at 11:49:01AM +0100, Oleksij Rempel wrote:
> >> Add devicetree label property for usbnet devices and related yaml
> >> schema.
> > That says _what_ you are doing, but not _why_ you would want to do such
> > a crazy thing, nor what problem you are attempting to solve here.
> 
> could you at least describe what kind of systems we are talking
> about? Is this for a limited set of embedded devices?
> Are we talking about devices embedded on a motherboard,
> which happen to be connected by USB?

In this particular use case there is a PCB with a imx6 SoC with hard
wired USB attached USB-Ethernet-MAC adapters. One of these adapters is
connected in the same PCB to an Ethernet switch chip. There is a DSA
driver for the switch, so we want to describe the whole boards in a DT.
Putting a label in the DT that renames the network interface is "nice to
have" but not so important.

As the DT DSA bindings rely on linking a MAC phandle to the switch we
need to describe the USB Ethernet adapter in the DT, this is more
important. See this discussion:

https://lore.kernel.org/all/20220127120039.GE9150@pengutronix.de/

> That is, are we talking about another kind of firmware
> we are to take information about devices from?

There is no other firmware involved. The switch chip is attached via
RGMII to the USB/MAC and with SPI to the CPU for the configuration
interface. (I2C to the CPU or MDIO to the USB/MAC would be another
option for the configuration interface.)

> And if so, why are you proposing to solve this on the
> USB driver level?
> It looks to me like those devices are addressed by
> their USB path. But still there is no reason that a USB
> driver should actively interpret firmware stuff that
> comes from a source that tells us nothing about USB
> properties.
> In other words it looks to me like you are trying to put
> a generic facility for getting device properties into
> a specific driver. The question whether device names
> should be read out of firmware is not a USB question.
> 
> I would suggest you implement a generic facility
> in the network layer and if everybody is happy with that
> obviously usbnet can pass through a pointer for that
> to operate on. Frankly, it looks to me like you are
> implementing only a subset of what device tree
> could contain for your specific use case.

Sounds good, but we'll focus on the DSA use case, as this is more
important. So patches 1 and 2 of this patches set have highest prio for
us.

Regards,
Oleksij & Marc
Oliver Neukum Feb. 3, 2022, 1:16 p.m. UTC | #4
On 03.02.22 11:27, Oleksij Rempel wrote:
> On Thu, Feb 03, 2022 at 10:34:25AM +0100, Oliver Neukum wrote:
>> On 27.01.22 11:57, Greg KH wrote:
>>> On Thu, Jan 27, 2022 at 11:49:01AM +0100, Oleksij Rempel wrote:
>>>
> In this particular use case there is a PCB with a imx6 SoC with hard
> wired USB attached USB-Ethernet-MAC adapters. One of these adapters is
> connected in the same PCB to an Ethernet switch chip. There is a DSA
> driver for the switch, so we want to describe the whole boards in a DT.
OK, so you are talking about what is technically an embedded
device with a DT as is usual for such devices.
> Putting a label in the DT that renames the network interface is "nice to
> have" but not so important.
Well, this applies to your particular device only, doesn't it?
>
> As the DT DSA bindings rely on linking a MAC phandle to the switch we
> need to describe the USB Ethernet adapter in the DT, this is more
> important. See this discussion:
>
> https://lore.kernel.org/all/20220127120039.GE9150@pengutronix.de/
And this one irks me. The USB list is not the place to talk about
how to build switches. The question here is whether OF and
DSA have features that need support in USB drivers.

I am not ready to discuss the merits of features in OF
>> I would suggest you implement a generic facility
>> in the network layer and if everybody is happy with that
>> obviously usbnet can pass through a pointer for that
>> to operate on. Frankly, it looks to me like you are
>> implementing only a subset of what device tree
>> could contain for your specific use case.
> Sounds good, but we'll focus on the DSA use case, as this is more
> important. So patches 1 and 2 of this patches set have highest prio for
> us.
It looks to me like you want a layering violation for
a special case. Is there any reason for you not to provide
a generic helper in the networking core?

    Regards
        Oliver