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
| ||
|
Message-ID: <CAJq09z5PoaOUW22k_8Raw07-jyC45ZpgiojgL1WP59oDQC3REQ@mail.gmail.com> 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
Powered by blists - more mailing lists