netdev - Re: [PATCH net-next 01/13] dt-bindings: net: dsa: realtek-smi: remove unsupported switches

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]

Date:   Sat, 18 Dec 2021 03:41:00 +0100
From:   Linus Walleij <linus.walleij@...aro.org>
To:     luizluca@...il.com
Cc:     netdev@...r.kernel.org, andrew@...n.ch, vivien.didelot@...il.com,
        f.fainelli@...il.com, olteanv@...il.com, ALSI@...g-olufsen.dk,
        arinc.unal@...nc9.com
Subject: Re: [PATCH net-next 01/13] dt-bindings: net: dsa: realtek-smi: remove
 unsupported switches

On Thu, Dec 16, 2021 at 9:14 PM <luizluca@...il.com> wrote:

> From: Luiz Angelo Daros de Luca <luizluca@...il.com>
>
> Remove some switch models that are not cited in the code. Although rtl8366s
> was kept, it looks like a stub driver (with a FIXME comment).
>
> Reviewed-by: Arınç ÜNAL <arinc.unal@...nc9.com>
> Signed-off-by: Luiz Angelo Daros de Luca <luizluca@...il.com>

Why? The device tree bindings are done with the ambition to be used
on several operating systems and the fact that the code in the Linux
kernel is not using them or citing them is not a reason to remove them.
We often define bindings for devices which don't even have a driver
in Linux.

A reason to delete them would be if they are family names and not
product names, i.e. no devices have this printed on the package.
I have seen physical packages saying "RTL8366RB" and
"RTL8366S" for sure, the rest I don't know about...

So we need compatibles for each physically existing component
that people might want to put in their device tree. Whether they have
drivers or not.

Yours,
Linus Walleij