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

From: Andrew Lunn <andrew@lunn.ch>
To: Luiz Angelo Daros de Luca <luizluca@gmail.com>
Cc: "open list:NETWORKING DRIVERS" <netdev@vger.kernel.org>,
	linux-doc@vger.kernel.org,
	"Tobias Waldekranz" <tobias@waldekranz.com>,
	"Florian Fainelli" <f.fainelli@gmail.com>,
	"Vladimir Oltean" <vladimir.oltean@nxp.com>,
	corbet@lwn.net, "Jakub Kicinski" <kuba@kernel.org>,
	"David S. Miller" <davem@davemloft.net>,
	"Arınç ÜNAL" <arinc.unal@arinc9.com>
Subject: Re: [PATCH net-next] net: dsa: realtek: add compatible strings for RTL8367RB-VB
Date: Tue, 12 Apr 2022 14:43:06 +0200	[thread overview]
Message-ID: <YlVz2gqXbgtFZUhA@lunn.ch> (raw)
In-Reply-To: <CAJq09z7CDbaFdjkmqiZsPM1He4o+szMEJANDiaZTCo_oi+ZCSQ@mail.gmail.com>

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.

> 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.

    Andrew