netdev - Re: [PATCH net-next] net: dsa: realtek: add compatible strings for RTL8367RB-VB

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: <CAJq09z7CDbaFdjkmqiZsPM1He4o+szMEJANDiaZTCo_oi+ZCSQ@mail.gmail.com>
Date:   Tue, 12 Apr 2022 01:12:51 -0300
From:   Luiz Angelo Daros de Luca <luizluca@...il.com>
To:     Andrew Lunn <andrew@...n.ch>
Cc:     "open list:NETWORKING DRIVERS" <netdev@...r.kernel.org>,
        linux-doc@...r.kernel.org,
        Tobias Waldekranz <tobias@...dekranz.com>,
        Florian Fainelli <f.fainelli@...il.com>,
        Vladimir Oltean <vladimir.oltean@....com>, corbet@....net,
        Jakub Kicinski <kuba@...nel.org>,
        "David S. Miller" <davem@...emloft.net>,
        Arınç ÜNAL <arinc.unal@...nc9.com>
Subject: Re: [PATCH net-next] net: dsa: realtek: add compatible strings for RTL8367RB-VB

> On Mon, Apr 11, 2022 at 06:04:07PM -0300, Luiz Angelo Daros de Luca wrote:
> > RTL8367RB-VB was not mentioned in the compatible table, nor in the
> > Kconfig help text.
> >
> > The driver still detects the variant by itself and ignores which
> > compatible string was used to select it. So, any compatible string will
> > work for any compatible model.
>
> Meaning the compatible string is pointless, and cannot be trusted. So
> yes, you can add it, but don't actually try to use it for anything,
> like quirks.

Thanks, Andrew. Those compatible strings are indeed useless for now.
The driver probes the chip variant. Maybe in the future, if required,
we could provide a way to either force a model or let it autodetect as
it does today.

There is no "family name" for those devices. The best we had was
rtl8367c (with "c" probably meaning 3rd family). I suggested renaming
the driver to rtl8367c but, in the end, we kept it as the first
supported device name. My plan is, at least, to allow the user to
specify the correct model without knowing which model it is equivalent
to.

Regards,

Luiz