All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Alvin Šipraga" <ALSI@bang-olufsen.dk>
To: "Arınç ÜNAL" <arinc.unal@arinc9.com>
Cc: Luiz Angelo Daros de Luca <luizluca@gmail.com>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	"linus.walleij@linaro.org" <linus.walleij@linaro.org>,
	"andrew@lunn.ch" <andrew@lunn.ch>,
	"vivien.didelot@gmail.com" <vivien.didelot@gmail.com>,
	"f.fainelli@gmail.com" <f.fainelli@gmail.com>,
	"olteanv@gmail.com" <olteanv@gmail.com>,
	"davem@davemloft.net" <davem@davemloft.net>,
	"kuba@kernel.org" <kuba@kernel.org>,
	"pabeni@redhat.com" <pabeni@redhat.com>,
	"robh+dt@kernel.org" <robh+dt@kernel.org>,
	"krzk+dt@kernel.org" <krzk+dt@kernel.org>,
	"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>
Subject: Re: [PATCH net v2 1/2] dt-bindings: net: dsa: realtek: cleanup compatible strings
Date: Tue, 19 Apr 2022 13:10:39 +0000	[thread overview]
Message-ID: <20220419131038.7fb2f4pthsiyugho@bang-olufsen.dk> (raw)
In-Reply-To: <41b4c9c7-871a-83c4-5df0-24b85ce0cb24@arinc9.com>

On Tue, Apr 19, 2022 at 03:47:40AM +0300, Arınç ÜNAL wrote:
> On 19/04/2022 02:35, Luiz Angelo Daros de Luca 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.
> > 
> > The removed compatible strings have never been used in a released kernel.
> > 
> > CC: devicetree@vger.kernel.org
> > Link: https://lore.kernel.org/netdev/20220414014055.m4wbmr7tdz6hsa3m@bang-olufsen.dk/
> > Signed-off-by: Luiz Angelo Daros de Luca <luizluca@gmail.com>
> 
> Do we know the chip ID and version of all of the switches this driver _can_
> support? So we have all the switches actually supported under a single
> compatible string.
> 
> The chip ID seems to be the same across all the switches under this defacto
> rtl8367c family.

Some of them will have a different chip ID, but we haven't had anyone try those
switches yet. Currently they will be unsupported, and I wouldn't want to claim
otherwise though because nobody has actually tested. There are small differences
per switch but in general these differences disappear if they have the same chip
ID. To give a more precise answer will require a lot more detail which I don't
think is relevant, but if you are curious, you can check how the vendor driver
does the detection and what the different parameters then are:

https://github.com/openwrt/openwrt/blob/aae7af4219e56c2787f675109d9dd1a44a5dcba4/target/linux/mediatek/files-5.10/drivers/net/phy/rtk/rtl8367c/rtk_switch.c#L712

> 
> Alvin, could your contacts at Realtek provide the chip ID and version for
> the switches we don’t know:
> RTL8363NB, RTL8363NB-VB, RTL8363SC, RTL8363SC-VB, RTL8364NB, RTL8364NB-VB,
> RTL8366SC, RTL8367SB, RTL8370MB, RTL8310SR

I'll ask my contact at Realtek if he can give me a full list of chip/version
values per switch, but given that the vendor driver is already doing similar
auto-detection, I think it is safe to assume that we don't require an additional
compatible string for the switches listed in Luiz' patch. The vendor driver
simply doesn't have a very granular check - presumably because the switches in
this family share many similarities - so it's not possible to infer the
chip/version ID per switch.

Kind regards,
Alvin

  reply	other threads:[~2022-04-19 13:10 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-04-18 23:35 [PATCH net v2 1/2] dt-bindings: net: dsa: realtek: cleanup compatible strings Luiz Angelo Daros de Luca
2022-04-18 23:35 ` [PATCH net v2 2/2] net: dsa: realtek: remove realtek,rtl8367s string Luiz Angelo Daros de Luca
2022-04-18 23:48   ` Andrew Lunn
2022-04-19  0:43   ` Arınç ÜNAL
2022-04-18 23:48 ` [PATCH net v2 1/2] dt-bindings: net: dsa: realtek: cleanup compatible strings Andrew Lunn
2022-04-19  0:47 ` Arınç ÜNAL
2022-04-19 13:10   ` Alvin Šipraga [this message]
2022-04-19 13:13 ` Alvin Šipraga
2022-04-20 10:10 ` patchwork-bot+netdevbpf
2022-04-20 20:29   ` Luiz Angelo Daros de Luca
2022-04-22 17:56     ` Jakub Kicinski
2022-04-25 18:48 ` Rob Herring
2022-04-27 21:43   ` Luiz Angelo Daros de Luca

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20220419131038.7fb2f4pthsiyugho@bang-olufsen.dk \
    --to=alsi@bang-olufsen.dk \
    --cc=andrew@lunn.ch \
    --cc=arinc.unal@arinc9.com \
    --cc=davem@davemloft.net \
    --cc=devicetree@vger.kernel.org \
    --cc=f.fainelli@gmail.com \
    --cc=krzk+dt@kernel.org \
    --cc=kuba@kernel.org \
    --cc=linus.walleij@linaro.org \
    --cc=luizluca@gmail.com \
    --cc=netdev@vger.kernel.org \
    --cc=olteanv@gmail.com \
    --cc=pabeni@redhat.com \
    --cc=robh+dt@kernel.org \
    --cc=vivien.didelot@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.