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

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: <802305c6-10b6-27e6-d154-83ee0abe3aeb@gmail.com>
Date: Sun, 4 Jun 2023 15:01:27 +0200
From: Christian Lamparter <chunkeey@...il.com>
To: Alvin Šipraga <ALSI@...g-olufsen.dk>
Cc: "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
 "luizluca@...il.com" <luizluca@...il.com>,
 "linus.walleij@...aro.org" <linus.walleij@...aro.org>,
 "andrew@...n.ch" <andrew@...n.ch>, "olteanv@...il.com" <olteanv@...il.com>,
 "f.fainelli@...il.com" <f.fainelli@...il.com>
Subject: Re: [PATCH v1] net: dsa: realtek: rtl8365mb: add missing case for
 digital interface 0

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