netdev - Re: [PATCH net-next v1 0/4] usbnet: add "label" support

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <Yfut/RbMAoaIhx41@pengutronix.de>
Date:   Thu, 3 Feb 2022 11:27:09 +0100
From:   Oleksij Rempel <o.rempel@...gutronix.de>
To:     Oliver Neukum <oneukum@...e.com>
Cc:     Greg KH <gregkh@...uxfoundation.org>,
        "David S. Miller" <davem@...emloft.net>,
        Jakub Kicinski <kuba@...nel.org>,
        Rob Herring <robh+dt@...nel.org>, kernel@...gutronix.de,
        linux-kernel@...r.kernel.org, linux-usb@...r.kernel.org,
        netdev@...r.kernel.org, devicetree@...r.kernel.org
Subject: Re: [PATCH net-next v1 0/4] usbnet: add "label" support

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
-- 
Pengutronix e.K.                           |                             |
Steuerwalder Str. 21                       | http://www.pengutronix.de/  |
31137 Hildesheim, Germany                  | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |