Date:   Wed, 13 Apr 2022 15:29:45 -0300
From:   Luiz Angelo Daros de Luca <luizluca@...il.com>
To:     Alvin Šipraga <ALSI@...g-olufsen.dk>
Cc:     Andrew Lunn <andrew@...n.ch>,
        "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.

The Realtek driver (rtl8367c) does provide a way to skip the probe and
force a specific model detection. Maybe that is a requirement for some
kind of device we might see in the future. If needed, we could add a
new property ("autodetect-{model,variant} = false") to force the model
based only on the compatible string. It would also allow a compatible
device to use the driver even if its ids are not known by the driver.

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

I wouldn't say it is wrong but not as specific as possible.
"compatible" seems to indicate that a driver from modelA can be used
for modelB.
We could start to warn the user when the compatible string does not
match the model (at least from what we already know).

Today, the driver only uses the model to tell the CPU and user ports
(and chip version is enough for that usage). However, the vendor
driver does an independent probe when it is setting the external port
and it does check additional registers. Today the Linux driver only
supports RGMII without actually checking if the model does support it.
When we expand that support to other port modes, we might need to
revisit the chip probe.

> > It is also something you cannot retrospectively make useful, because
> > of all those broken DT blobs.

We cannot tell if there are other models that share the same chip
version (from reg 0x1302). We can only tell from the devices we have
access to. Yes, there might already be a device using a different
compatible string from the real device and I don't intend to break it.

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

Yes, Alvin. Thanks.

It feels strange to force the user to use "realtek,rtl8365mb" or any
other different string that does not match the chip's real name. I
would not expect the one writing the DT to know that rtl8367s shares
the same family with rtl8365mb and rtl8365mb driver does support
rtl8367s. Before writing the rtl8367s driver, I also didn't know the
relation between those chips. The common was only to relate rtl8367s
(or any other chip model) with the vendor driver rtl8367c. As we don't
have a generic family string, I think it is better to add every model
variant.

Regards,

Luiz

Powered by blists - more mailing lists