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: <20220412133055.vmzz2copvu2qzzin@bang-olufsen.dk>
Date:   Tue, 12 Apr 2022 13:30:56 +0000
From:   Alvin Šipraga <ALSI@...g-olufsen.dk>
To:     Andrew Lunn <andrew@...n.ch>
CC:     Luiz Angelo Daros de Luca <luizluca@...il.com>,
        "open list:NETWORKING DRIVERS" <netdev@...r.kernel.org>,
        "linux-doc@...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" <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 Tue, Apr 12, 2022 at 02:43:06PM +0200, Andrew Lunn wrote:
> On Tue, Apr 12, 2022 at 01:12:51AM -0300, Luiz Angelo Daros de Luca wrote:
> > > 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.
> 
> The problem is, you have to assume some percentage of shipped DT blobs
> have the wrong compatible string, but work because it is not actually
> used in a meaningful way. This is why the couple of dozen Marvell
> switches have just 3 compatible strings, which is enough to find the
> ID registers to identify the actual switch. The three compatibles are
> the name of the lowest chip in the family which introduced to location
> of the ID register.

Right, this was basically the original behaviour:

- realtek,rtl8265mb -> use rtl8365mb.c subdriver
- realtek,rtl8366rb -> use rtl8366rb.c subdriver (different family with different register layout)

We then check a chip ID/version register and store that in the driver-private
data, in case of quirks or different behaviours between chips in the same
family.

I think Andrew has a point that adding more compatible strings is not really
going to add any tangible benefit, due to the above bahviour. People can equally
well just put one of the above two compatible strings.

> 
> > 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.
> 
> In order words, you are quite happy to allow the DT author to get is
> wrong, and do not care it is wrong. So the percentage of DT blobs with
> the wrong compatible will go up, making it even more useless.
> 
> It is also something you cannot retrospectively make useful, because
> of all those broken DT blobs.

I think Luiz is saying he wants to allow device tree authors to write
"realtek,rtl8367rb" if their hardware really does have an RTL8367RB switch and
not an RTL8365MB, rather than writing "realtek,rtl8365mb". But an enterprising
device tree author could just as well write:

	 compatible = "realtek,rtl8367rb", "realtek,rtl8365mb";

... which would work without us having to continually add more (arguably
useless) compatible strings to the driver, including this one.

Kind regards,
Alvin