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: <39e8899f-f5e0-c57c-ebaa-f3303a716d0d@suse.com>
Date:   Thu, 3 Feb 2022 14:16:09 +0100
From:   Oliver Neukum <oneukum@...e.com>
To:     Oleksij Rempel <o.rempel@...gutronix.de>,
        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 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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ