[PATCH v1] net: dsa: realtek: rtl8365mb: add missing case for digital interface 0

[PATCH v1] net: dsa: realtek: rtl8365mb: add missing case for digital interface 0

[Christian Lamparter]

when bringing up the switch on a Netgear WNDAP660, I observed that
no traffic got passed from the RTL8363 to the ethernet interface...

Turns out, this was because the dropped case for
RTL8365MB_DIGITAL_INTERFACE_SELECT_REG(0) that
got deleted by accident.

Fixes: d18b59f48b31 ("net: dsa: realtek: rtl8365mb: rename extport to extint")
Signed-off-by: Christian Lamparter <chunkeey@gmail.com>
---
RTL8365MB_DIGITAL_INTERFACE_SELECT_REG(0) is shared between
extif0 and extif1. There's an extra
RTL8365MB_DIGITAL_INTERFACE_SELECT_MODE_MASK later on to diffy
up between bits for extif0 and extif1.
---
 drivers/net/dsa/realtek/rtl8365mb.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/net/dsa/realtek/rtl8365mb.c b/drivers/net/dsa/realtek/rtl8365mb.c
index 6c00e6dcb193..57aa39f5b341 100644
--- a/drivers/net/dsa/realtek/rtl8365mb.c
+++ b/drivers/net/dsa/realtek/rtl8365mb.c
@@ -209,7 +209,8 @@
 #define RTL8365MB_DIGITAL_INTERFACE_SELECT_REG0		0x1305 /* EXT1 */
 #define RTL8365MB_DIGITAL_INTERFACE_SELECT_REG1		0x13C3 /* EXT2 */
 #define RTL8365MB_DIGITAL_INTERFACE_SELECT_REG(_extint) \
-		((_extint) == 1 ? RTL8365MB_DIGITAL_INTERFACE_SELECT_REG0 : \
+		((_extint) == 0 ? RTL8365MB_DIGITAL_INTERFACE_SELECT_REG0 : \
+		 (_extint) == 1 ? RTL8365MB_DIGITAL_INTERFACE_SELECT_REG0 : \
 		 (_extint) == 2 ? RTL8365MB_DIGITAL_INTERFACE_SELECT_REG1 : \
 		 0x0)
 #define   RTL8365MB_DIGITAL_INTERFACE_SELECT_MODE_MASK(_extint) \
-- 
2.40.1

Re: [PATCH v1] net: dsa: realtek: rtl8365mb: add missing case for digital interface 0

[Alvin Šipraga]

On Sat, Jun 03, 2023 at 12:53:48AM +0200, Christian Lamparter wrote:
> when bringing up the switch on a Netgear WNDAP660, I observed that
> no traffic got passed from the RTL8363 to the ethernet interface...

Could you share the chip ID/version you read out from this RTL8363SB? I haven't
seen this part number but maybe it's equivalent to some other known switch.

> 
> Turns out, this was because the dropped case for
> RTL8365MB_DIGITAL_INTERFACE_SELECT_REG(0) that
> got deleted by accident.

Could you show where exactly this macro is called with 0 as an argument? AFAICT
this patch doesn't change anything, as the macro is called in only one place
with rtl8365mb_extint::id as an argument, but these id fields are statically
populated in rtl8365mb_chip_info and I only see values 1 or 2 there.

If you are introducing support for a new switch, why not just use a value of 1
instead? The macro will then map to ..._REG0 as you desire.

Kind regards,
Alvin

> 
> Fixes: d18b59f48b31 ("net: dsa: realtek: rtl8365mb: rename extport to extint")
> Signed-off-by: Christian Lamparter <chunkeey@gmail.com>
> ---
> RTL8365MB_DIGITAL_INTERFACE_SELECT_REG(0) is shared between
> extif0 and extif1. There's an extra
> RTL8365MB_DIGITAL_INTERFACE_SELECT_MODE_MASK later on to diffy
> up between bits for extif0 and extif1.
> ---
>  drivers/net/dsa/realtek/rtl8365mb.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/net/dsa/realtek/rtl8365mb.c b/drivers/net/dsa/realtek/rtl8365mb.c
> index 6c00e6dcb193..57aa39f5b341 100644
> --- a/drivers/net/dsa/realtek/rtl8365mb.c
> +++ b/drivers/net/dsa/realtek/rtl8365mb.c
> @@ -209,7 +209,8 @@
>  #define RTL8365MB_DIGITAL_INTERFACE_SELECT_REG0		0x1305 /* EXT1 */
>  #define RTL8365MB_DIGITAL_INTERFACE_SELECT_REG1		0x13C3 /* EXT2 */
>  #define RTL8365MB_DIGITAL_INTERFACE_SELECT_REG(_extint) \
> -		((_extint) == 1 ? RTL8365MB_DIGITAL_INTERFACE_SELECT_REG0 : \
> +		((_extint) == 0 ? RTL8365MB_DIGITAL_INTERFACE_SELECT_REG0 : \
> +		 (_extint) == 1 ? RTL8365MB_DIGITAL_INTERFACE_SELECT_REG0 : \
>  		 (_extint) == 2 ? RTL8365MB_DIGITAL_INTERFACE_SELECT_REG1 : \
>  		 0x0)
>  #define   RTL8365MB_DIGITAL_INTERFACE_SELECT_MODE_MASK(_extint) \
> -- 
> 2.40.1
>

Re: [PATCH v1] net: dsa: realtek: rtl8365mb: add missing case for digital interface 0

[Christian Lamparter]

On 6/4/23 13:13, Alvin Šipraga wrote:
> On Sat, Jun 03, 2023 at 12:53:48AM +0200, Christian Lamparter wrote:
>> when bringing up the switch on a Netgear WNDAP660, I observed that
>> no traffic got passed from the RTL8363 to the ethernet interface...
> 
> Could you share the chip ID/version you read out from this RTL8363SB? I haven't
> seen this part number but maybe it's equivalent to some other known switch.

Sure Chip ID is 0x6000 and Chip Version is 0x1000. The label on the physical chip itself:

RTL8363SB
B8E77P2
GC17 TAIWAN

I also have a preliminary patch that just adds the switch to the
rtl8365mb_chip_info table. (The -CG came from Googling after RTL8363SB)
---
--- a/drivers/net/dsa/realtek/rtl8365mb.c
+++ b/drivers/net/dsa/realtek/rtl8365mb.c
@@ -519,6 +519,19 @@ struct rtl8365mb_chip_info {
  /* Chip info for each supported switch in the family */
  #define PHY_INTF(_mode) (RTL8365MB_PHY_INTERFACE_MODE_ ## _mode)
  static const struct rtl8365mb_chip_info rtl8365mb_chip_infos[] = {
+	{
+		.name = "RTL8363SB-CG",
+		.chip_id = 0x6000,
+		.chip_ver = 0x1000,
+		.extints = {
+			{ 5, 0, PHY_INTF(MII) | PHY_INTF(TMII) |
+				PHY_INTF(RMII) | PHY_INTF(RGMII) },
+			{ 6, 1, PHY_INTF(MII) | PHY_INTF(TMII) |
+				PHY_INTF(RMII) | PHY_INTF(RGMII) },
+		},
+		.jam_table = rtl8365mb_init_jam_8365mb_vc,
+		.jam_size = ARRAY_SIZE(rtl8365mb_init_jam_8365mb_vc),
+	},
  	{
  		.name = "RTL8365MB-VC",
  		.chip_id = 0x6367,
---

currently, the WNDAP660 works with the out-of-tree rtl8367b.c from openwrt:
<https://git.openwrt.org/?p=openwrt/openwrt.git;a=blob;f=target/linux/apm821xx/dts/netgear-wndap6x0.dtsi>

|         rtl8367b {
|                 compatible = "realtek,rtl8367b";
|                 cpu_port = <5>;
|                 realtek,extif0 = <1 2 1 1 1 1 1 1 2>;
|                 mii-bus = <&mdio0>;
|         };

<https://git.openwrt.org/?p=openwrt/openwrt.git;a=blob;f=target/linux/apm821xx/dts/netgear-wndap660.dts>

>> Turns out, this was because the dropped case for
>> RTL8365MB_DIGITAL_INTERFACE_SELECT_REG(0) that
>> got deleted by accident.
> 
> Could you show where exactly this macro is called with 0 as an argument? AFAICT
> this patch doesn't change anything, as the macro is called in only one place
> with rtl8365mb_extint::id as an argument, but these id fields are statically
> populated in rtl8365mb_chip_info and I only see values 1 or 2 there.
> 
> If you are introducing support for a new switch, why not just use a value of 1
> instead? The macro will then map to ..._REG0 as you desire.

No, Value "1" sadly does not work. Other macros like
RTL8365MB_DIGITAL_INTERFACE_SELECT_MODE_MASK(_extint) and
RTL8365MB_EXT_RGMXF_REG(_extint) do support "0" just as before. i.e:

<https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/net/dsa/realtek/rtl8365mb.c#n224>
#define RTL8365MB_EXT_RGMXF_REG(_extint) \
                ((_extint) == 0 ? RTL8365MB_EXT_RGMXF_REG0 : \
                 (_extint) == 1 ? RTL8365MB_EXT_RGMXF_REG1 : \
                 (_extint) == 2 ? RTL8365MB_EXT_RGMXF_REG2 : \
                 0x0

The patch "net: dsa: realtek: rtl8365mb: rename extport to extint" mentioned
removed:

-#define RTL8365MB_DIGITAL_INTERFACE_SELECT_REG(_extport)   \
-               (RTL8365MB_DIGITAL_INTERFACE_SELECT_REG0 + \
-                ((_extport) >> 1) * (0x13C3 - 0x1305))

and replaced it with:

+#define RTL8365MB_DIGITAL_INTERFACE_SELECT_REG(_extint) \
+               ((_extint) == 1 ? RTL8365MB_DIGITAL_INTERFACE_SELECT_REG0 : \
+                (_extint) == 2 ? RTL8365MB_DIGITAL_INTERFACE_SELECT_REG1 : \
+                0x0)

so with the old RTL8365MB_DIGITAL_INTERFACE_SELECT_REG(0) evaluated to
(RTL8365MB_DIGITAL_INTERFACE_SELECT_REG0+(0) (which is 0x1305) and
since the patch RTL8365MB_DIGITAL_INTERFACE_SELECT_REG(0) evaluates to
0. So the driver writes to somewhere it shouldn't (in my RTL8363SB)
case.

so that's why I said it was "by accident" in the commit message.
Since the other macros stayed intact.

 From what I can gleam, Luiz patch mentions at the end:
"[...] and ext_id 0 does not seem to be used as well for this family."

Looking around in todays OpenWrt's various DTS. There are these devices:

extif0:
TP-Link WR2543-v1
SFR Neufbox 6 (Sercomm)
Edimax BR-6475nD
Samsung CY-SWR1100
(Netgear WNDAP660 + WNDAP620)

extif1:
Asus RT-N56U
D-Link DIR-645
TP-Link Archer C2 v1
I-O DATA WN-AC733GR3

extif2:
ZyXEL Keenetic Viva

Since this discovery, I do now have something that sort of works.
If you have a different values for extif0/export1, I sure can adapt
them no problem.

Cheers,
Christian

Re: [PATCH v1] net: dsa: realtek: rtl8365mb: add missing case for digital interface 0

[Alvin Šipraga]

On Sun, Jun 04, 2023 at 03:01:27PM +0200, Christian Lamparter wrote:
> On 6/4/23 13:13, Alvin Šipraga wrote:
> > On Sat, Jun 03, 2023 at 12:53:48AM +0200, Christian Lamparter wrote:
> > > when bringing up the switch on a Netgear WNDAP660, I observed that
> > > no traffic got passed from the RTL8363 to the ethernet interface...
> > 
> > Could you share the chip ID/version you read out from this RTL8363SB? I haven't
> > seen this part number but maybe it's equivalent to some other known switch.
> 
> Sure Chip ID is 0x6000 and Chip Version is 0x1000. The label on the physical chip itself:
> 
> RTL8363SB
> B8E77P2
> GC17 TAIWAN

Thanks, please include when you send the patch which adds the chip_info!

> 
> I also have a preliminary patch that just adds the switch to the
> rtl8365mb_chip_info table. (The -CG came from Googling after RTL8363SB)
> ---
> --- a/drivers/net/dsa/realtek/rtl8365mb.c
> +++ b/drivers/net/dsa/realtek/rtl8365mb.c
> @@ -519,6 +519,19 @@ struct rtl8365mb_chip_info {
>  /* Chip info for each supported switch in the family */
>  #define PHY_INTF(_mode) (RTL8365MB_PHY_INTERFACE_MODE_ ## _mode)
>  static const struct rtl8365mb_chip_info rtl8365mb_chip_infos[] = {
> +	{
> +		.name = "RTL8363SB-CG",
> +		.chip_id = 0x6000,
> +		.chip_ver = 0x1000,
> +		.extints = {
> +			{ 5, 0, PHY_INTF(MII) | PHY_INTF(TMII) |
> +				PHY_INTF(RMII) | PHY_INTF(RGMII) },
> +			{ 6, 1, PHY_INTF(MII) | PHY_INTF(TMII) |
> +				PHY_INTF(RMII) | PHY_INTF(RGMII) },
> +		},
> +		.jam_table = rtl8365mb_init_jam_8365mb_vc,
> +		.jam_size = ARRAY_SIZE(rtl8365mb_init_jam_8365mb_vc),
> +	},
>  	{
>  		.name = "RTL8365MB-VC",
>  		.chip_id = 0x6367,
> ---
> 
> currently, the WNDAP660 works with the out-of-tree rtl8367b.c from openwrt:
> <https://git.openwrt.org/?p=openwrt/openwrt.git;a=blob;f=target/linux/apm821xx/dts/netgear-wndap6x0.dtsi>
> 
> |         rtl8367b {
> |                 compatible = "realtek,rtl8367b";
> |                 cpu_port = <5>;
> |                 realtek,extif0 = <1 2 1 1 1 1 1 1 2>;
> |                 mii-bus = <&mdio0>;
> |         };
> 
> <https://git.openwrt.org/?p=openwrt/openwrt.git;a=blob;f=target/linux/apm821xx/dts/netgear-wndap660.dts>
> 
> > > Turns out, this was because the dropped case for
> > > RTL8365MB_DIGITAL_INTERFACE_SELECT_REG(0) that
> > > got deleted by accident.
> > 
> > Could you show where exactly this macro is called with 0 as an argument? AFAICT
> > this patch doesn't change anything, as the macro is called in only one place
> > with rtl8365mb_extint::id as an argument, but these id fields are statically
> > populated in rtl8365mb_chip_info and I only see values 1 or 2 there.
> > 
> > If you are introducing support for a new switch, why not just use a value of 1
> > instead? The macro will then map to ..._REG0 as you desire.
> 
> No, Value "1" sadly does not work. Other macros like
> RTL8365MB_DIGITAL_INTERFACE_SELECT_MODE_MASK(_extint) and
> RTL8365MB_EXT_RGMXF_REG(_extint) do support "0" just as before. i.e:
> 
> <https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/net/dsa/realtek/rtl8365mb.c#n224>
> #define RTL8365MB_EXT_RGMXF_REG(_extint) \
>                ((_extint) == 0 ? RTL8365MB_EXT_RGMXF_REG0 : \
>                 (_extint) == 1 ? RTL8365MB_EXT_RGMXF_REG1 : \
>                 (_extint) == 2 ? RTL8365MB_EXT_RGMXF_REG2 : \
>                 0x0
> 
> The patch "net: dsa: realtek: rtl8365mb: rename extport to extint" mentioned
> removed:
> 
> -#define RTL8365MB_DIGITAL_INTERFACE_SELECT_REG(_extport)   \
> -               (RTL8365MB_DIGITAL_INTERFACE_SELECT_REG0 + \
> -                ((_extport) >> 1) * (0x13C3 - 0x1305))
> 
> and replaced it with:
> 
> +#define RTL8365MB_DIGITAL_INTERFACE_SELECT_REG(_extint) \
> +               ((_extint) == 1 ? RTL8365MB_DIGITAL_INTERFACE_SELECT_REG0 : \
> +                (_extint) == 2 ? RTL8365MB_DIGITAL_INTERFACE_SELECT_REG1 : \
> +                0x0)
> 
> so with the old RTL8365MB_DIGITAL_INTERFACE_SELECT_REG(0) evaluated to
> (RTL8365MB_DIGITAL_INTERFACE_SELECT_REG0+(0) (which is 0x1305) and
> since the patch RTL8365MB_DIGITAL_INTERFACE_SELECT_REG(0) evaluates to
> 0. So the driver writes to somewhere it shouldn't (in my RTL8363SB)
> case.

Ah yes, I see what you mean now. OK, so 0 is indeed valid. Please include this
extra info in your v2 message :)

Also I suggest marking REG0 as EXT0 and EXT1, something like this:

#define RTL8365MB_DIGITAL_INTERFACE_SELECT_REG0		0x1305 /* EXT0/EXT1 */

> 
> so that's why I said it was "by accident" in the commit message.
> Since the other macros stayed intact.

Yes, agree. Do you agree with me though that this doesn't warrant backporting to
stable as there is no functional change with just the patch on its own?
i.e. this should be part of a broader series adding RTL8363SB-CG support
targetting net-next. (The Fixes: tag is absolutely fine ofc - stable maintainers
will tell you that this does not necessarily mean it should go in stable, that's
what cc: stable@vger is for). If so please add [PATCH v2 net-next] so it goes in
the right place.

> 
> From what I can gleam, Luiz patch mentions at the end:
> "[...] and ext_id 0 does not seem to be used as well for this family."
> 
> Looking around in todays OpenWrt's various DTS. There are these devices:
> 
> extif0:
> TP-Link WR2543-v1
> SFR Neufbox 6 (Sercomm)
> Edimax BR-6475nD
> Samsung CY-SWR1100
> (Netgear WNDAP660 + WNDAP620)

Hm, hard to comment without knowing the exact chip. But if you couldn't get it
to work with 1 or 2, I guess 0 is correct. The vendor sources refer to an EXT0
here and there after all.

Kind regards,
Alvin

> 
> extif1:
> Asus RT-N56U
> D-Link DIR-645
> TP-Link Archer C2 v1
> I-O DATA WN-AC733GR3
> 
> extif2:
> ZyXEL Keenetic Viva
> 
> Since this discovery, I do now have something that sort of works.
> If you have a different values for extif0/export1, I sure can adapt
> them no problem.
> 
> Cheers,
> Christian

Re: [PATCH v1] net: dsa: realtek: rtl8365mb: add missing case for digital interface 0

[Luiz Angelo Daros de Luca]

> > The patch "net: dsa: realtek: rtl8365mb: rename extport to extint" mentioned
> > removed:
> >
> > -#define RTL8365MB_DIGITAL_INTERFACE_SELECT_REG(_extport)   \
> > -               (RTL8365MB_DIGITAL_INTERFACE_SELECT_REG0 + \
> > -                ((_extport) >> 1) * (0x13C3 - 0x1305))
> >
> > and replaced it with:
> >
> > +#define RTL8365MB_DIGITAL_INTERFACE_SELECT_REG(_extint) \
> > +               ((_extint) == 1 ? RTL8365MB_DIGITAL_INTERFACE_SELECT_REG0 : \
> > +                (_extint) == 2 ? RTL8365MB_DIGITAL_INTERFACE_SELECT_REG1 : \
> > +                0x0)
> >
> > so with the old RTL8365MB_DIGITAL_INTERFACE_SELECT_REG(0) evaluated to
> > (RTL8365MB_DIGITAL_INTERFACE_SELECT_REG0+(0) (which is 0x1305) and
> > since the patch RTL8365MB_DIGITAL_INTERFACE_SELECT_REG(0) evaluates to
> > 0. So the driver writes to somewhere it shouldn't (in my RTL8363SB)
> > case.
>
> Ah yes, I see what you mean now. OK, so 0 is indeed valid. Please include this
> extra info in your v2 message :)

Yes, the vendor rtl8367c driver does use it for both ext0 and ext1.

if(0 == id || 1 == id)
        {
                ...RTL8367C_REG_DIGITAL_INTERFACE_SELECT...
        }
        else
        {
                ...RTL8367C_REG_DIGITAL_INTERFACE_SELECT_1
        }

But being in the vendor driver does not automatically mean there is a
model that supports that interface, as drivers usually evolve from
previous generation drivers, sometimes leaving unused references
behind. As we didn't have a device supported that used ext0, I
deliberately left it out. There are other features that are not
included in the driver until a device requires them.

But being in the vendor driver does not automatically mean there is a
model that supports that interface as drivers normally grow from
previous generation drivers, sometimes leaving references not used
anymore. As we didn't have a device supported that used ext0, I
deliberately left it out. There are other features not included in the
driver until a device does require it.

> Also I suggest marking REG0 as EXT0 and EXT1, something like this:
>
> #define RTL8365MB_DIGITAL_INTERFACE_SELECT_REG0         0x1305 /* EXT0/EXT1 */
>
> >
> > so that's why I said it was "by accident" in the commit message.
> > Since the other macros stayed intact.
>
> Yes, agree. Do you agree with me though that this doesn't warrant backporting to
> stable as there is no functional change with just the patch on its own?
> i.e. this should be part of a broader series adding RTL8363SB-CG support
> targetting net-next. (The Fixes: tag is absolutely fine ofc - stable maintainers
> will tell you that this does not necessarily mean it should go in stable, that's
> what cc: stable@vger is for). If so please add [PATCH v2 net-next] so it goes in
> the right place.
>
> >
> > From what I can gleam, Luiz patch mentions at the end:
> > "[...] and ext_id 0 does not seem to be used as well for this family."
>

When I say "family", I mean:

RTL8363NB
RTL8364NB
RTL8365MB-VC
RTL8367RB-VB
RTL8367SB
RTL8367S
RTL8366SC
RTL8363SC
RTL8370MB
RTL8310SR
RTL8363NB-VB
RTL8364NB-VB
RTL8363SC-VB

And your device is:

RTL8363SB

Realtek product names do not help too much to limit which device is
closer to which other. I'm not saying for sure that none of those I
listed does not use ext0 (I was at the time, but not now without
reviewing lots of docs/code), but it looks like your device is from a
previous generation. And if rtl8365mb.c does work, that's great. We
are expanding the family.

> > Looking around in todays OpenWrt's various DTS. There are these devices:
> >
> > extif0:
> > TP-Link WR2543-v1
> > SFR Neufbox 6 (Sercomm)
> > Edimax BR-6475nD
> > Samsung CY-SWR1100
> > (Netgear WNDAP660 + WNDAP620)

I didn't check all devices but I own a TP-Link WR2543-v1. I'm not sure
if RTL8367R in TP-Link WR2543-v1 is compatible with rtl8365mb.c
driver. In OpenWrt, we have all these realtek swconfig drivers:
- rtl8366
- rtl8366s
- rtl8366rb (should support the same device as DSA rtl8366rb.c driver
but not used there yet)
- rtl8367 (compatible with RTL8367R and RTL8367M)
- rtl8367b
- rtk-gsw / rtl8367c / rtl8367s_gsw (this one is actually the vendor
driver for the same rtl8365mb.c family but statically configured for
rtl8367s)

You can compare rtl8367.c with rtl8367b.c to get an idea of what would
be needed to change in the rtl8365mb.c to include support for those
devices supported by rtl8367 (if the CPU tag is compatible). The only
models I'm sure rtl8365mb.c will work out-of-box are those using the
rtk-gsw (compatible string) because they are only using the RTL8367S
chip. You can see that driver in the mediatek target at
target/linux/mediatek/files/drivers/net/phy/rtk/. The ones using
swconfig rtl8367b might work with rtl8365mb.c as your device was
compatible with that driver and it seems to be working with
rtl8365mb.c after some adjustments. BTW, even RTL8367S was working
with swconfig rtl8367b with some minor touches (see
https://github.com/openwrt/openwrt/pull/2174/files).

Regards,

Luiz

Re: [PATCH v1] net: dsa: realtek: rtl8365mb: add missing case for digital interface 0

[Jakub Kicinski]

On Sun, 4 Jun 2023 19:19:45 +0000 Alvin Šipraga wrote:
> > so that's why I said it was "by accident" in the commit message.
> > Since the other macros stayed intact.  
> 
> Yes, agree. Do you agree with me though that this doesn't warrant backporting to
> stable as there is no functional change with just the patch on its own?
> i.e. this should be part of a broader series adding RTL8363SB-CG support
> targetting net-next.

+1

> (The Fixes: tag is absolutely fine ofc - stable maintainers
> will tell you that this does not necessarily mean it should go in stable, that's
> what cc: stable@vger is for). If so please add [PATCH v2 net-next] so it goes in
> the right place.

I'd remove the Fixes tag as well, and clearly state in the commit msg
that this patch is a noop for all devices currently supported upstream.
-- 
pw-bot: cr

Re: [PATCH v1] net: dsa: realtek: rtl8365mb: add missing case for digital interface 0

[Alvin Šipraga]

On Sun, Jun 04, 2023 at 03:01:27PM +0200, Christian Lamparter wrote:
> On 6/4/23 13:13, Alvin Šipraga wrote:
> > On Sat, Jun 03, 2023 at 12:53:48AM +0200, Christian Lamparter wrote:
> > > when bringing up the switch on a Netgear WNDAP660, I observed that
> > > no traffic got passed from the RTL8363 to the ethernet interface...
> > 
> > Could you share the chip ID/version you read out from this RTL8363SB? I haven't
> > seen this part number but maybe it's equivalent to some other known switch.
> 
> Sure Chip ID is 0x6000 and Chip Version is 0x1000. The label on the physical chip itself:
> 
> RTL8363SB
> B8E77P2
> GC17 TAIWAN
> 
> I also have a preliminary patch that just adds the switch to the
> rtl8365mb_chip_info table. (The -CG came from Googling after RTL8363SB)
> ---
> --- a/drivers/net/dsa/realtek/rtl8365mb.c
> +++ b/drivers/net/dsa/realtek/rtl8365mb.c
> @@ -519,6 +519,19 @@ struct rtl8365mb_chip_info {
>  /* Chip info for each supported switch in the family */
>  #define PHY_INTF(_mode) (RTL8365MB_PHY_INTERFACE_MODE_ ## _mode)
>  static const struct rtl8365mb_chip_info rtl8365mb_chip_infos[] = {
> +	{
> +		.name = "RTL8363SB-CG",

Btw, when you send the patch, omit the -CG. The RTL8365MB-VC for example also
has a -CG suffix but this is not relevant as it refers to the package being of
'Green' type (whatever that means), not the silicon revision. :)