netdev - Re: [PATCH net 1/2] dt-bindings: net: dsa: realtek: cleanup compatible strings

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:   Mon, 18 Apr 2022 20:05:27 -0300
From:   Luiz Angelo Daros de Luca <luizluca@...il.com>
To:     Linus Walleij <linus.walleij@...aro.org>
Cc:     "open list:NETWORKING DRIVERS" <netdev@...r.kernel.org>,
        Alvin Šipraga <ALSI@...g-olufsen.dk>,
        Andrew Lunn <andrew@...n.ch>,
        Vivien Didelot <vivien.didelot@...il.com>,
        Florian Fainelli <f.fainelli@...il.com>,
        Vladimir Oltean <olteanv@...il.com>,
        "David S. Miller" <davem@...emloft.net>,
        Jakub Kicinski <kuba@...nel.org>,
        Paolo Abeni <pabeni@...hat.com>,
        Rob Herring <robh+dt@...nel.org>, krzk+dt@...nel.org,
        Arınç ÜNAL <arinc.unal@...nc9.com>,
        devicetree@...r.kernel.org
Subject: Re: [PATCH net 1/2] dt-bindings: net: dsa: realtek: cleanup
 compatible strings

> On Sat, Apr 16, 2022 at 8:25 AM Luiz Angelo Daros de Luca
> <luizluca@...il.com> wrote:
>
> > Compatible strings are used to help the driver find the chip ID/version
> > register for each chip family. After that, the driver can setup the
> > switch accordingly. Keep only the first supported model for each family
> > as a compatible string and reference other chip models in the
> > description.
> >
> > CC: devicetree@...r.kernel.org
> > Link: https://lore.kernel.org/netdev/20220414014055.m4wbmr7tdz6hsa3m@bang-olufsen.dk/
> > Signed-off-by: Luiz Angelo Daros de Luca <luizluca@...il.com>
>
> OK, I suppose we know that Realtek has always maintained the
> ID numbers in the hardware? Otherwise we will end up where
> bindings/arm/primecell.yaml is: hardware ID numbers that were
> supposed to be updated but weren't, so now both DT and the
> kernel has to go through all kinds of loops and hoops to make it
> work by encoding the number that should have been in the
> hardware is instead in the device tree...

Thanks, Linus. The rtl8367c driver seems to depend on information
retrieved from registers, mainly chip id/ver. If they forget to update
a chip id/version, it might be the case that it does not really matter
from the driver's point of view.
Anyway, if deemed to be necessary, adding a compatible string is much
easier than removing one after a kernel is released.

Regards,

Luiz