[PATCH net-next 0/5] net: dsa: realtek: rtl8365mb: improve handling of PHY modes

[PATCH net-next 0/5] net: dsa: realtek: rtl8365mb: improve handling of PHY modes

[Alvin Šipraga]

From: Alvin Šipraga <alsi@bang-olufsen.dk>

This series introduces some minor cleanup of the driver and improves the
handling of PHY interface modes to break the assumption that CPU ports
are always over an external interface, and the assumption that user
ports are always using an internal PHY.

Alvin Šipraga (5):
  net: dsa: realtek: rtl8365mb: rename macro RTL8367RB -> RTL8367RB_VB
  net: dsa: realtek: rtl8365mb: remove port_mask private data member
  net: dsa: realtek: rtl8365mb: correct the max number of ports
  net: dsa: realtek: rtl8365mb: remove learn_limit_max private data
    member
  net: dsa: realtek: rtl8365mb: handle PHY interface modes correctly

 drivers/net/dsa/realtek/rtl8365mb.c | 268 ++++++++++++++++++++--------
 1 file changed, 189 insertions(+), 79 deletions(-)

-- 
2.36.0

[PATCH net-next 1/5] net: dsa: realtek: rtl8365mb: rename macro RTL8367RB -> RTL8367RB_VB

[Alvin Šipraga]

From: Alvin Šipraga <alsi@bang-olufsen.dk>

The official name of this switch is RTL8367RB-VB, not RTL8367RB. There
is also an RTL8367RB-VC which is rather different. Change the name of
the CHIP_ID/_VER macros for reasons of consistency.

Signed-off-by: Alvin Šipraga <alsi@bang-olufsen.dk>
---
 drivers/net/dsa/realtek/rtl8365mb.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/net/dsa/realtek/rtl8365mb.c b/drivers/net/dsa/realtek/rtl8365mb.c
index 3bb42a9f236d..0cc90e96aab7 100644
--- a/drivers/net/dsa/realtek/rtl8365mb.c
+++ b/drivers/net/dsa/realtek/rtl8365mb.c
@@ -108,8 +108,8 @@
 #define RTL8365MB_CHIP_ID_8367S		0x6367
 #define RTL8365MB_CHIP_VER_8367S	0x00A0
 
-#define RTL8365MB_CHIP_ID_8367RB	0x6367
-#define RTL8365MB_CHIP_VER_8367RB	0x0020
+#define RTL8365MB_CHIP_ID_8367RB_VB	0x6367
+#define RTL8365MB_CHIP_VER_8367RB_VB	0x0020
 
 /* Family-specific data and limits */
 #define RTL8365MB_PHYADDRMAX		7
@@ -2008,7 +2008,7 @@ static int rtl8365mb_detect(struct realtek_priv *priv)
 				 "found an RTL8365MB-VC switch (ver=0x%04x)\n",
 				 chip_ver);
 			break;
-		case RTL8365MB_CHIP_VER_8367RB:
+		case RTL8365MB_CHIP_VER_8367RB_VB:
 			dev_info(priv->dev,
 				 "found an RTL8367RB-VB switch (ver=0x%04x)\n",
 				 chip_ver);
-- 
2.36.0

Re: [PATCH net-next 1/5] net: dsa: realtek: rtl8365mb: rename macro RTL8367RB -> RTL8367RB_VB

[Luiz Angelo Daros de Luca]

Reviewed-by: Luiz Angelo Daros de Luca <luizluca@gmail.com>

[PATCH net-next 2/5] net: dsa: realtek: rtl8365mb: remove port_mask private data member

[Alvin Šipraga]

From: Alvin Šipraga <alsi@bang-olufsen.dk>

There is no real need for this variable: the line change interrupt mask
is sufficiently masked out when getting linkup_ind and linkdown_ind in
the interrupt handler.

Signed-off-by: Alvin Šipraga <alsi@bang-olufsen.dk>
---
 drivers/net/dsa/realtek/rtl8365mb.c | 5 +----
 1 file changed, 1 insertion(+), 4 deletions(-)

diff --git a/drivers/net/dsa/realtek/rtl8365mb.c b/drivers/net/dsa/realtek/rtl8365mb.c
index 0cc90e96aab7..c64219271a2b 100644
--- a/drivers/net/dsa/realtek/rtl8365mb.c
+++ b/drivers/net/dsa/realtek/rtl8365mb.c
@@ -564,7 +564,6 @@ struct rtl8365mb_port {
  * @irq: registered IRQ or zero
  * @chip_id: chip identifier
  * @chip_ver: chip silicon revision
- * @port_mask: mask of all ports
  * @learn_limit_max: maximum number of L2 addresses the chip can learn
  * @cpu: CPU tagging and CPU port configuration for this chip
  * @mib_lock: prevent concurrent reads of MIB counters
@@ -579,7 +578,6 @@ struct rtl8365mb {
 	int irq;
 	u32 chip_id;
 	u32 chip_ver;
-	u32 port_mask;
 	u32 learn_limit_max;
 	struct rtl8365mb_cpu cpu;
 	struct mutex mib_lock;
@@ -1540,7 +1538,7 @@ static irqreturn_t rtl8365mb_irq(int irq, void *data)
 
 		linkdown_ind = FIELD_GET(RTL8365MB_PORT_LINKDOWN_IND_MASK, val);
 
-		line_changes = (linkup_ind | linkdown_ind) & mb->port_mask;
+		line_changes = linkup_ind | linkdown_ind;
 	}
 
 	if (!line_changes)
@@ -2029,7 +2027,6 @@ static int rtl8365mb_detect(struct realtek_priv *priv)
 		mb->priv = priv;
 		mb->chip_id = chip_id;
 		mb->chip_ver = chip_ver;
-		mb->port_mask = GENMASK(priv->num_ports - 1, 0);
 		mb->learn_limit_max = RTL8365MB_LEARN_LIMIT_MAX;
 		mb->jam_table = rtl8365mb_init_jam_8365mb_vc;
 		mb->jam_size = ARRAY_SIZE(rtl8365mb_init_jam_8365mb_vc);
-- 
2.36.0

Re: [PATCH net-next 2/5] net: dsa: realtek: rtl8365mb: remove port_mask private data member

[Luiz Angelo Daros de Luca]

> There is no real need for this variable: the line change interrupt mask
> is sufficiently masked out when getting linkup_ind and linkdown_ind in
> the interrupt handler.

Yes, it was currently useless as well as priv->num_ports (it is a constant).

I wonder if we should really create irq threads for unused ports
(!dsa_is_unused_port()). Some models have only 2+1 ports and we are
always dealing with 10/11 ports.
If dsa_is_unused_port() is too costly to be used everywhere, we could
keep port_mask and iterate over it (for_each_set_bit) instead of from
0 til priv->num_ports-1.

Regards,

Luiz

Re: [PATCH net-next 2/5] net: dsa: realtek: rtl8365mb: remove port_mask private data member

[Alvin Šipraga]

On Tue, Jun 07, 2022 at 10:34:38AM -0300, Luiz Angelo Daros de Luca wrote:
> > There is no real need for this variable: the line change interrupt mask
> > is sufficiently masked out when getting linkup_ind and linkdown_ind in
> > the interrupt handler.
> 
> Yes, it was currently useless as well as priv->num_ports (it is a constant).
> 
> I wonder if we should really create irq threads for unused ports
> (!dsa_is_unused_port()). Some models have only 2+1 ports and we are
> always dealing with 10/11 ports.
> If dsa_is_unused_port() is too costly to be used everywhere, we could
> keep port_mask and iterate over it (for_each_set_bit) instead of from
> 0 til priv->num_ports-1.

Seems like premature optimization, I prefer to keep it simple.

Kind regards,
Alvin

[PATCH net-next 3/5] net: dsa: realtek: rtl8365mb: correct the max number of ports

[Alvin Šipraga]

From: Alvin Šipraga <alsi@bang-olufsen.dk>

The maximum number of ports is actually 11, according to two
observations:

1. The highest port ID used in the vendor driver is 10. Since port IDs
   are indexed from 0, and since DSA follows the same numbering system,
   this means up to 11 ports are to be presumed.

2. The registers with port mask fields always amount to a maximum port
   mask of 0x7FF, corresponding to a maximum 11 ports.

In view of this, I also deleted the comment.

Signed-off-by: Alvin Šipraga <alsi@bang-olufsen.dk>
---
 drivers/net/dsa/realtek/rtl8365mb.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/net/dsa/realtek/rtl8365mb.c b/drivers/net/dsa/realtek/rtl8365mb.c
index c64219271a2b..392047558656 100644
--- a/drivers/net/dsa/realtek/rtl8365mb.c
+++ b/drivers/net/dsa/realtek/rtl8365mb.c
@@ -115,8 +115,7 @@
 #define RTL8365MB_PHYADDRMAX		7
 #define RTL8365MB_NUM_PHYREGS		32
 #define RTL8365MB_PHYREGMAX		(RTL8365MB_NUM_PHYREGS - 1)
-/* RTL8370MB and RTL8310SR, possibly suportable by this driver, have 10 ports */
-#define RTL8365MB_MAX_NUM_PORTS		10
+#define RTL8365MB_MAX_NUM_PORTS		11
 #define RTL8365MB_LEARN_LIMIT_MAX	2112
 
 /* valid for all 6-port or less variants */
-- 
2.36.0

Re: [PATCH net-next 3/5] net: dsa: realtek: rtl8365mb: correct the max number of ports

[Luiz Angelo Daros de Luca]

Em seg., 6 de jun. de 2022 às 10:46, Alvin Šipraga <alvin@pqrs.dk> escreveu:
>
> From: Alvin Šipraga <alsi@bang-olufsen.dk>
>
> The maximum number of ports is actually 11, according to two
> observations:
>
> 1. The highest port ID used in the vendor driver is 10. Since port IDs
>    are indexed from 0, and since DSA follows the same numbering system,
>    this means up to 11 ports are to be presumed.
>
> 2. The registers with port mask fields always amount to a maximum port
>    mask of 0x7FF, corresponding to a maximum 11 ports.
>  /* valid for all 6-port or less variants */

It makes sense for the family. The 10-ports variants have 0-7 user
ports and ext0,1,2 declared in rtl8367c driver, although no model I
know does use ext2.

Reviewed-by: Luiz Angelo Daros de Luca <luizluca@gmail.com>

[PATCH net-next 4/5] net: dsa: realtek: rtl8365mb: remove learn_limit_max private data member

[Alvin Šipraga]

From: Alvin Šipraga <alsi@bang-olufsen.dk>

The variable is just assigned the value of a macro, so it can be
removed.

Signed-off-by: Alvin Šipraga <alsi@bang-olufsen.dk>
---
 drivers/net/dsa/realtek/rtl8365mb.c | 7 +------
 1 file changed, 1 insertion(+), 6 deletions(-)

diff --git a/drivers/net/dsa/realtek/rtl8365mb.c b/drivers/net/dsa/realtek/rtl8365mb.c
index 392047558656..a3a4454f77bf 100644
--- a/drivers/net/dsa/realtek/rtl8365mb.c
+++ b/drivers/net/dsa/realtek/rtl8365mb.c
@@ -563,7 +563,6 @@ struct rtl8365mb_port {
  * @irq: registered IRQ or zero
  * @chip_id: chip identifier
  * @chip_ver: chip silicon revision
- * @learn_limit_max: maximum number of L2 addresses the chip can learn
  * @cpu: CPU tagging and CPU port configuration for this chip
  * @mib_lock: prevent concurrent reads of MIB counters
  * @ports: per-port data
@@ -577,7 +576,6 @@ struct rtl8365mb {
 	int irq;
 	u32 chip_id;
 	u32 chip_ver;
-	u32 learn_limit_max;
 	struct rtl8365mb_cpu cpu;
 	struct mutex mib_lock;
 	struct rtl8365mb_port ports[RTL8365MB_MAX_NUM_PORTS];
@@ -1108,15 +1106,13 @@ static void rtl8365mb_port_stp_state_set(struct dsa_switch *ds, int port,
 static int rtl8365mb_port_set_learning(struct realtek_priv *priv, int port,
 				       bool enable)
 {
-	struct rtl8365mb *mb = priv->chip_data;
-
 	/* Enable/disable learning by limiting the number of L2 addresses the
 	 * port can learn. Realtek documentation states that a limit of zero
 	 * disables learning. When enabling learning, set it to the chip's
 	 * maximum.
 	 */
 	return regmap_write(priv->map, RTL8365MB_LUT_PORT_LEARN_LIMIT_REG(port),
-			    enable ? mb->learn_limit_max : 0);
+			    enable ? RTL8365MB_LEARN_LIMIT_MAX : 0);
 }
 
 static int rtl8365mb_port_set_isolation(struct realtek_priv *priv, int port,
@@ -2026,7 +2022,6 @@ static int rtl8365mb_detect(struct realtek_priv *priv)
 		mb->priv = priv;
 		mb->chip_id = chip_id;
 		mb->chip_ver = chip_ver;
-		mb->learn_limit_max = RTL8365MB_LEARN_LIMIT_MAX;
 		mb->jam_table = rtl8365mb_init_jam_8365mb_vc;
 		mb->jam_size = ARRAY_SIZE(rtl8365mb_init_jam_8365mb_vc);
 
-- 
2.36.0

Re: [PATCH net-next 4/5] net: dsa: realtek: rtl8365mb: remove learn_limit_max private data member

[Luiz Angelo Daros de Luca]

> The variable is just assigned the value of a macro, so it can be
> removed.

The 10-ports devices do use a different value.

    <10 ports
    /* MAX LUT Address Number */
   2112,

    10-ports
    /* MAX LUT Address Number 4096 + 64*/
   4160,

I guess learn_limit_max could be migrated to the new
rtl8365mb_chip_info structure.

Regards,

Luiz

[PATCH net-next 5/5] net: dsa: realtek: rtl8365mb: handle PHY interface modes correctly

[Alvin Šipraga]

From: Alvin Šipraga <alsi@bang-olufsen.dk>

Realtek switches in the rtl8365mb family always have at least one port
with a so-called external interface, supporting PHY interface modes such
as RGMII or SGMII. The purpose of this patch is to improve the driver's
handling of these ports.

A new struct rtl8365mb_chip_info is introduced. A static instance of
this struct is added for each supported switch, which is distinguished
by its chip ID and version. Embedded in each chip_info struct is an
array of struct rtl8365mb_extint, describing the external interfaces
available. This is more specific than the old rtl8365mb_extint_port_map,
which was only valid for switches with up to 6 ports.

The struct rtl8365mb_extint also contains a bitmask of supported PHY
interface modes, which allows the driver to distinguish which ports
support RGMII. This corrects a previous mistake in the driver whereby it
was assumed that any port with an external interface supports RGMII.
This is not actually the case: for example, the RTL8367S has two
external interfaces, only the second of which supports RGMII. The first
supports only SGMII and HSGMII. This new design will make it easier to
add support for other interface modes.

Finally, rtl8365mb_phylink_get_caps() is fixed up to return supported
capabilities based on the external interface properties described above.
This allows for ports with an external interface to be treated as DSA
user ports, and for ports with an internal PHY to be treated as DSA CPU
ports.

Link: https://lore.kernel.org/netdev/20220510192301.5djdt3ghoavxulhl@bang-olufsen.dk/
Signed-off-by: Alvin Šipraga <alsi@bang-olufsen.dk>
---
 drivers/net/dsa/realtek/rtl8365mb.c | 247 +++++++++++++++++++++-------
 1 file changed, 183 insertions(+), 64 deletions(-)

diff --git a/drivers/net/dsa/realtek/rtl8365mb.c b/drivers/net/dsa/realtek/rtl8365mb.c
index a3a4454f77bf..2dc0459af5a4 100644
--- a/drivers/net/dsa/realtek/rtl8365mb.c
+++ b/drivers/net/dsa/realtek/rtl8365mb.c
@@ -118,9 +118,6 @@
 #define RTL8365MB_MAX_NUM_PORTS		11
 #define RTL8365MB_LEARN_LIMIT_MAX	2112
 
-/* valid for all 6-port or less variants */
-static const int rtl8365mb_extint_port_map[]  = { -1, -1, -1, -1, -1, -1, 1, 2, -1, -1};
-
 /* Chip identification registers */
 #define RTL8365MB_CHIP_ID_REG		0x1300
 
@@ -200,7 +197,7 @@ static const int rtl8365mb_extint_port_map[]  = { -1, -1, -1, -1, -1, -1, 1, 2,
 /* The PHY OCP addresses of PHY registers 0~31 start here */
 #define RTL8365MB_PHY_OCP_ADDR_PHYREG_BASE		0xA400
 
-/* EXT interface port mode values - used in DIGITAL_INTERFACE_SELECT */
+/* External interface port mode values - used in DIGITAL_INTERFACE_SELECT */
 #define RTL8365MB_EXT_PORT_MODE_DISABLE		0
 #define RTL8365MB_EXT_PORT_MODE_RGMII		1
 #define RTL8365MB_EXT_PORT_MODE_MII_MAC		2
@@ -216,19 +213,7 @@ static const int rtl8365mb_extint_port_map[]  = { -1, -1, -1, -1, -1, -1, 1, 2,
 #define RTL8365MB_EXT_PORT_MODE_1000X		12
 #define RTL8365MB_EXT_PORT_MODE_100FX		13
 
-/* Realtek docs and driver uses logic number as EXT_PORT0=16, EXT_PORT1=17,
- * EXT_PORT2=18, to interact with switch ports. That logic number is internally
- * converted to either a physical port number (0..9) or an external interface id (0..2),
- * depending on which function was called. The external interface id is calculated as
- * (ext_id=logic_port-15), while the logical to physical map depends on the chip id/version.
- *
- * EXT_PORT0 mentioned in datasheets and rtl8367c driver is used in this driver
- * as extid==1, EXT_PORT2, mentioned in Realtek rtl8367c driver for 10-port switches,
- * would have an ext_id of 3 (out of range for most extint macros) and ext_id 0 does
- * not seem to be used as well for this family.
- */
-
-/* EXT interface mode configuration registers 0~1 */
+/* External interface mode configuration registers 0~1 */
 #define RTL8365MB_DIGITAL_INTERFACE_SELECT_REG0		0x1305 /* EXT1 */
 #define RTL8365MB_DIGITAL_INTERFACE_SELECT_REG1		0x13C3 /* EXT2 */
 #define RTL8365MB_DIGITAL_INTERFACE_SELECT_REG(_extint) \
@@ -240,7 +225,7 @@ static const int rtl8365mb_extint_port_map[]  = { -1, -1, -1, -1, -1, -1, 1, 2,
 #define   RTL8365MB_DIGITAL_INTERFACE_SELECT_MODE_OFFSET(_extint) \
 		(((_extint) % 2) * 4)
 
-/* EXT interface RGMII TX/RX delay configuration registers 0~2 */
+/* External interface RGMII TX/RX delay configuration registers 0~2 */
 #define RTL8365MB_EXT_RGMXF_REG0		0x1306 /* EXT0 */
 #define RTL8365MB_EXT_RGMXF_REG1		0x1307 /* EXT1 */
 #define RTL8365MB_EXT_RGMXF_REG2		0x13C5 /* EXT2 */
@@ -257,7 +242,7 @@ static const int rtl8365mb_extint_port_map[]  = { -1, -1, -1, -1, -1, -1, 1, 2,
 #define RTL8365MB_PORT_SPEED_100M	1
 #define RTL8365MB_PORT_SPEED_1000M	2
 
-/* EXT interface force configuration registers 0~2 */
+/* External interface force configuration registers 0~2 */
 #define RTL8365MB_DIGITAL_INTERFACE_FORCE_REG0		0x1310 /* EXT0 */
 #define RTL8365MB_DIGITAL_INTERFACE_FORCE_REG1		0x1311 /* EXT1 */
 #define RTL8365MB_DIGITAL_INTERFACE_FORCE_REG2		0x13C4 /* EXT2 */
@@ -489,6 +474,100 @@ static const struct rtl8365mb_jam_tbl_entry rtl8365mb_init_jam_common[] = {
 	{ 0x1D32, 0x0002 },
 };
 
+enum rtl8365mb_phy_interface_mode {
+	RTL8365MB_PHY_INTERFACE_MODE_INVAL = 0, /* used as sentinel */
+	RTL8365MB_PHY_INTERFACE_MODE_INTERNAL = BIT(0),
+	RTL8365MB_PHY_INTERFACE_MODE_MII = BIT(1),
+	RTL8365MB_PHY_INTERFACE_MODE_TMII = BIT(2),
+	RTL8365MB_PHY_INTERFACE_MODE_RMII = BIT(3),
+	RTL8365MB_PHY_INTERFACE_MODE_RGMII = BIT(4),
+	RTL8365MB_PHY_INTERFACE_MODE_SGMII = BIT(5),
+	RTL8365MB_PHY_INTERFACE_MODE_HSGMII = BIT(6),
+};
+
+/**
+ * struct rtl8365mb_extint - external interface info
+ * @port: the port with an external interface
+ * @id: the external interface ID, which is either 0, 1, or 2
+ * @supported_interfaces: a bitmask of supported PHY interface modes
+ *
+ * Represents a mapping: port -> { id, supported_interfaces }. To be embedded
+ * in &struct rtl8365mb_chip_info for every port with an external interface.
+ */
+struct rtl8365mb_extint {
+	int port;
+	int id;
+	unsigned int supported_interfaces;
+};
+
+/**
+ * struct rtl8365mb_chip_info - static chip-specific info
+ * @name: human-readable chip name
+ * @chip_id: chip identifier
+ * @chip_ver: chip silicon revision
+ * @jam_table: chip-specific initialization jam table
+ * @jam_size: size of the chip's jam table
+ * @extints: external interfaces, followed by a zero sentinel
+ *
+ * These data are specific to a given chip in the family of switches supported
+ * by this driver. When adding support for another chip in the family, a new
+ * static struct of this type should be defined, and assigned in the
+ * rtl8365mb_detect() function based on chip ID/version.
+ */
+struct rtl8365mb_chip_info {
+	const char *name;
+	u32 chip_id;
+	u32 chip_ver;
+	const struct rtl8365mb_jam_tbl_entry *jam_table;
+	size_t jam_size;
+	const struct rtl8365mb_extint extints[];
+};
+
+/* 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_info_8365mb_vc = {
+	.name = "RTL8365MB-VC",
+	.chip_id = RTL8365MB_CHIP_ID_8365MB_VC,
+	.chip_ver = RTL8365MB_CHIP_VER_8365MB_VC,
+	.extints = {
+		{ 6, 1, PHY_INTF(MII) |	PHY_INTF(TMII) | PHY_INTF(RMII) |
+			PHY_INTF(RGMII) },
+		{ /* sentinel */ }
+	},
+	.jam_table = rtl8365mb_init_jam_8365mb_vc,
+	.jam_size = ARRAY_SIZE(rtl8365mb_init_jam_8365mb_vc),
+};
+
+static const struct rtl8365mb_chip_info rtl8365mb_chip_info_8367s = {
+	.name = "RTL8367S",
+	.chip_id = RTL8365MB_CHIP_ID_8367S,
+	.chip_ver = RTL8365MB_CHIP_VER_8367S,
+	.extints = {
+		{ 6, 1, PHY_INTF(SGMII) | PHY_INTF(HSGMII) },
+		{ 7, 2, PHY_INTF(MII) | PHY_INTF(TMII) | PHY_INTF(RMII) |
+			PHY_INTF(RGMII) },
+		{ /* sentinel */ }
+	},
+	.jam_table = rtl8365mb_init_jam_8365mb_vc,
+	.jam_size = ARRAY_SIZE(rtl8365mb_init_jam_8365mb_vc),
+};
+
+static const struct rtl8365mb_chip_info rtl8365mb_chip_info_8367rb_vb = {
+	.name = "RTL8367RB-VB",
+	.chip_id = RTL8365MB_CHIP_ID_8367RB_VB,
+	.chip_ver = RTL8365MB_CHIP_VER_8367RB_VB,
+	.extints = {
+		{ 6, 1, PHY_INTF(MII) | PHY_INTF(TMII) | PHY_INTF(RMII) |
+			PHY_INTF(RGMII) },
+		{ 7, 2, PHY_INTF(MII) | PHY_INTF(TMII) | PHY_INTF(RMII) |
+			PHY_INTF(RGMII) },
+		{ /* sentinel */ }
+	},
+	.jam_table = rtl8365mb_init_jam_8365mb_vc,
+	.jam_size = ARRAY_SIZE(rtl8365mb_init_jam_8365mb_vc),
+};
+
 enum rtl8365mb_stp_state {
 	RTL8365MB_STP_STATE_DISABLED = 0,
 	RTL8365MB_STP_STATE_BLOCKING = 1,
@@ -558,7 +637,7 @@ struct rtl8365mb_port {
 };
 
 /**
- * struct rtl8365mb - private chip-specific driver data
+ * struct rtl8365mb - driver private data
  * @priv: pointer to parent realtek_priv data
  * @irq: registered IRQ or zero
  * @chip_id: chip identifier
@@ -574,13 +653,10 @@ struct rtl8365mb_port {
 struct rtl8365mb {
 	struct realtek_priv *priv;
 	int irq;
-	u32 chip_id;
-	u32 chip_ver;
+	const struct rtl8365mb_chip_info *chip_info;
 	struct rtl8365mb_cpu cpu;
 	struct mutex mib_lock;
 	struct rtl8365mb_port ports[RTL8365MB_MAX_NUM_PORTS];
-	const struct rtl8365mb_jam_tbl_entry *jam_table;
-	size_t jam_size;
 };
 
 static int rtl8365mb_phy_poll_busy(struct realtek_priv *priv)
@@ -775,6 +851,31 @@ static int rtl8365mb_dsa_phy_write(struct dsa_switch *ds, int phy, int regnum,
 	return rtl8365mb_phy_write(ds->priv, phy, regnum, val);
 }
 
+const struct rtl8365mb_extint *
+rtl8365mb_get_port_extint(struct realtek_priv *priv, int port)
+{
+	struct rtl8365mb *mb = priv->chip_data;
+	const struct rtl8365mb_extint *extint;
+	const struct rtl8365mb_chip_info *ci;
+
+	ci = mb->chip_info;
+	extint = &ci->extints[0];
+
+	/* Every external interface supports at least one mode, so at least one
+	 * bit should be set in supported_interfaces. We use 0 as a sentinel,
+	 * cf. @RTL8265MB_PHY_INTERFACE_MODE_INVAL = 0.
+	 */
+	while (extint->supported_interfaces !=
+	       RTL8365MB_PHY_INTERFACE_MODE_INVAL) {
+		if (extint->port == port)
+			return extint;
+
+		extint++;
+	}
+
+	return NULL;
+}
+
 static enum dsa_tag_protocol
 rtl8365mb_get_tag_protocol(struct dsa_switch *ds, int port,
 			   enum dsa_tag_protocol mp)
@@ -795,18 +896,23 @@ rtl8365mb_get_tag_protocol(struct dsa_switch *ds, int port,
 static int rtl8365mb_ext_config_rgmii(struct realtek_priv *priv, int port,
 				      phy_interface_t interface)
 {
+	const struct rtl8365mb_extint *extint =
+		rtl8365mb_get_port_extint(priv, port);
 	struct device_node *dn;
 	struct dsa_port *dp;
 	int tx_delay = 0;
 	int rx_delay = 0;
-	int ext_int;
 	u32 val;
 	int ret;
 
-	ext_int = rtl8365mb_extint_port_map[port];
+	if (!extint) {
+		dev_err(priv->dev, "port %d has no external interface\n", port);
+		return -EINVAL;
+	}
 
-	if (ext_int <= 0) {
-		dev_err(priv->dev, "Port %d is not an external interface port\n", port);
+	if (!(extint->supported_interfaces &
+	      RTL8365MB_PHY_INTERFACE_MODE_RGMII)) {
+		dev_err(priv->dev, "port %d doesn't support RGMII\n", port);
 		return -EINVAL;
 	}
 
@@ -842,7 +948,7 @@ static int rtl8365mb_ext_config_rgmii(struct realtek_priv *priv, int port,
 			tx_delay = val / 2;
 		else
 			dev_warn(priv->dev,
-				 "EXT interface TX delay must be 0 or 2 ns\n");
+				 "RGMII TX delay must be 0 or 2 ns\n");
 	}
 
 	if (!of_property_read_u32(dn, "rx-internal-delay-ps", &val)) {
@@ -852,11 +958,11 @@ static int rtl8365mb_ext_config_rgmii(struct realtek_priv *priv, int port,
 			rx_delay = val;
 		else
 			dev_warn(priv->dev,
-				 "EXT interface RX delay must be 0 to 2.1 ns\n");
+				 "RGMII RX delay must be 0 to 2.1 ns\n");
 	}
 
 	ret = regmap_update_bits(
-		priv->map, RTL8365MB_EXT_RGMXF_REG(ext_int),
+		priv->map, RTL8365MB_EXT_RGMXF_REG(extint->id),
 		RTL8365MB_EXT_RGMXF_TXDELAY_MASK |
 			RTL8365MB_EXT_RGMXF_RXDELAY_MASK,
 		FIELD_PREP(RTL8365MB_EXT_RGMXF_TXDELAY_MASK, tx_delay) |
@@ -865,11 +971,11 @@ static int rtl8365mb_ext_config_rgmii(struct realtek_priv *priv, int port,
 		return ret;
 
 	ret = regmap_update_bits(
-		priv->map, RTL8365MB_DIGITAL_INTERFACE_SELECT_REG(ext_int),
-		RTL8365MB_DIGITAL_INTERFACE_SELECT_MODE_MASK(ext_int),
+		priv->map, RTL8365MB_DIGITAL_INTERFACE_SELECT_REG(extint->id),
+		RTL8365MB_DIGITAL_INTERFACE_SELECT_MODE_MASK(extint->id),
 		RTL8365MB_EXT_PORT_MODE_RGMII
 			<< RTL8365MB_DIGITAL_INTERFACE_SELECT_MODE_OFFSET(
-				   ext_int));
+				   extint->id));
 	if (ret)
 		return ret;
 
@@ -880,19 +986,18 @@ static int rtl8365mb_ext_config_forcemode(struct realtek_priv *priv, int port,
 					  bool link, int speed, int duplex,
 					  bool tx_pause, bool rx_pause)
 {
+	const struct rtl8365mb_extint *extint =
+		rtl8365mb_get_port_extint(priv, port);
 	u32 r_tx_pause;
 	u32 r_rx_pause;
 	u32 r_duplex;
 	u32 r_speed;
 	u32 r_link;
-	int ext_int;
 	int val;
 	int ret;
 
-	ext_int = rtl8365mb_extint_port_map[port];
-
-	if (ext_int <= 0) {
-		dev_err(priv->dev, "Port %d is not an external interface port\n", port);
+	if (!extint) {
+		dev_err(priv->dev, "port %d has no external interface\n", port);
 		return -EINVAL;
 	}
 
@@ -942,7 +1047,7 @@ static int rtl8365mb_ext_config_forcemode(struct realtek_priv *priv, int port,
 			 r_duplex) |
 	      FIELD_PREP(RTL8365MB_DIGITAL_INTERFACE_FORCE_SPEED_MASK, r_speed);
 	ret = regmap_write(priv->map,
-			   RTL8365MB_DIGITAL_INTERFACE_FORCE_REG(ext_int),
+			   RTL8365MB_DIGITAL_INTERFACE_FORCE_REG(extint->id),
 			   val);
 	if (ret)
 		return ret;
@@ -974,14 +1079,31 @@ static bool rtl8365mb_phy_mode_supported(struct dsa_switch *ds, int port,
 static void rtl8365mb_phylink_get_caps(struct dsa_switch *ds, int port,
 				       struct phylink_config *config)
 {
-	if (dsa_is_user_port(ds, port))
-		__set_bit(PHY_INTERFACE_MODE_INTERNAL,
-			  config->supported_interfaces);
-	else if (dsa_is_cpu_port(ds, port))
-		phy_interface_set_rgmii(config->supported_interfaces);
+	const struct rtl8365mb_extint *extint =
+		rtl8365mb_get_port_extint(ds->priv, port);
 
 	config->mac_capabilities = MAC_SYM_PAUSE | MAC_ASYM_PAUSE |
 				   MAC_10 | MAC_100 | MAC_1000FD;
+
+	if (!extint) {
+		__set_bit(PHY_INTERFACE_MODE_INTERNAL,
+			  config->supported_interfaces);
+
+		/* GMII is the default interface mode for phylib, so
+		 * we have to support it for ports with integrated PHY.
+		 */
+		__set_bit(PHY_INTERFACE_MODE_GMII,
+			  config->supported_interfaces);
+		return;
+	}
+
+	/* Populate according to the modes supported by _this driver_,
+	 * not necessarily the modes supported by the hardware, some of
+	 * which remain unimplemented.
+	 */
+
+	if (extint->supported_interfaces & RTL8365MB_PHY_INTERFACE_MODE_RGMII)
+		phy_interface_set_rgmii(config->supported_interfaces);
 }
 
 static void rtl8365mb_phylink_mac_config(struct dsa_switch *ds, int port,
@@ -1805,14 +1927,17 @@ static int rtl8365mb_change_tag_protocol(struct dsa_switch *ds,
 static int rtl8365mb_switch_init(struct realtek_priv *priv)
 {
 	struct rtl8365mb *mb = priv->chip_data;
+	const struct rtl8365mb_chip_info *ci;
 	int ret;
 	int i;
 
+	ci = mb->chip_info;
+
 	/* Do any chip-specific init jam before getting to the common stuff */
-	if (mb->jam_table) {
-		for (i = 0; i < mb->jam_size; i++) {
-			ret = regmap_write(priv->map, mb->jam_table[i].reg,
-					   mb->jam_table[i].val);
+	if (ci->jam_table) {
+		for (i = 0; i < ci->jam_size; i++) {
+			ret = regmap_write(priv->map, ci->jam_table[i].reg,
+					   ci->jam_table[i].val);
 			if (ret)
 				return ret;
 		}
@@ -1997,33 +2122,27 @@ static int rtl8365mb_detect(struct realtek_priv *priv)
 	case RTL8365MB_CHIP_ID_8365MB_VC:
 		switch (chip_ver) {
 		case RTL8365MB_CHIP_VER_8365MB_VC:
-			dev_info(priv->dev,
-				 "found an RTL8365MB-VC switch (ver=0x%04x)\n",
-				 chip_ver);
+			mb->chip_info = &rtl8365mb_chip_info_8365mb_vc;
 			break;
 		case RTL8365MB_CHIP_VER_8367RB_VB:
-			dev_info(priv->dev,
-				 "found an RTL8367RB-VB switch (ver=0x%04x)\n",
-				 chip_ver);
+			mb->chip_info = &rtl8365mb_chip_info_8367rb_vb;
 			break;
 		case RTL8365MB_CHIP_VER_8367S:
-			dev_info(priv->dev,
-				 "found an RTL8367S switch (ver=0x%04x)\n",
-				 chip_ver);
+			mb->chip_info = &rtl8365mb_chip_info_8367s;
 			break;
 		default:
-			dev_err(priv->dev, "unrecognized switch version (ver=0x%04x)",
-				chip_ver);
+			dev_err(priv->dev,
+				"unrecognized switch (id=0x%04x, ver=0x%04x)",
+				chip_id, chip_ver);
 			return -ENODEV;
 		}
 
+		dev_info(priv->dev, "found an %s switch\n",
+			 mb->chip_info->name);
+
 		priv->num_ports = RTL8365MB_MAX_NUM_PORTS;
 
 		mb->priv = priv;
-		mb->chip_id = chip_id;
-		mb->chip_ver = chip_ver;
-		mb->jam_table = rtl8365mb_init_jam_8365mb_vc;
-		mb->jam_size = ARRAY_SIZE(rtl8365mb_init_jam_8365mb_vc);
 
 		mb->cpu.trap_port = RTL8365MB_MAX_NUM_PORTS;
 		mb->cpu.insert = RTL8365MB_CPU_INSERT_TO_ALL;
-- 
2.36.0

Re: [PATCH net-next 5/5] net: dsa: realtek: rtl8365mb: handle PHY interface modes correctly

[Luiz Angelo Daros de Luca]

> From: Alvin Šipraga <alsi@bang-olufsen.dk>
>
> Realtek switches in the rtl8365mb family always have at least one port
> with a so-called external interface, supporting PHY interface modes such
> as RGMII or SGMII. The purpose of this patch is to improve the driver's
> handling of these ports.
>
> A new struct rtl8365mb_chip_info is introduced. A static instance of
> this struct is added for each supported switch, which is distinguished
> by its chip ID and version. Embedded in each chip_info struct is an
> array of struct rtl8365mb_extint, describing the external interfaces
> available. This is more specific than the old rtl8365mb_extint_port_map,
> which was only valid for switches with up to 6 ports.
>
> The struct rtl8365mb_extint also contains a bitmask of supported PHY
> interface modes, which allows the driver to distinguish which ports
> support RGMII. This corrects a previous mistake in the driver whereby it
> was assumed that any port with an external interface supports RGMII.
> This is not actually the case: for example, the RTL8367S has two
> external interfaces, only the second of which supports RGMII. The first
> supports only SGMII and HSGMII. This new design will make it easier to
> add support for other interface modes.
>
> Finally, rtl8365mb_phylink_get_caps() is fixed up to return supported
> capabilities based on the external interface properties described above.
> This allows for ports with an external interface to be treated as DSA
> user ports, and for ports with an internal PHY to be treated as DSA CPU
> ports.

That's a nice patch. But while dealing with ext interfaces, wouldn't
it be nice to also add
a mask for user ports? We could easily validate if a declared dsa port
really exists.

...

> @@ -1997,33 +2122,27 @@ static int rtl8365mb_detect(struct realtek_priv *priv)
>         case RTL8365MB_CHIP_ID_8365MB_VC:
>                 switch (chip_ver) {
>                 case RTL8365MB_CHIP_VER_8365MB_VC:
> -                       dev_info(priv->dev,
> -                                "found an RTL8365MB-VC switch (ver=0x%04x)\n",
> -                                chip_ver);
> +                       mb->chip_info = &rtl8365mb_chip_info_8365mb_vc;
>                         break;
>                 case RTL8365MB_CHIP_VER_8367RB_VB:
> -                       dev_info(priv->dev,
> -                                "found an RTL8367RB-VB switch (ver=0x%04x)\n",
> -                                chip_ver);
> +                       mb->chip_info = &rtl8365mb_chip_info_8367rb_vb;
>                         break;
>                 case RTL8365MB_CHIP_VER_8367S:
> -                       dev_info(priv->dev,
> -                                "found an RTL8367S switch (ver=0x%04x)\n",
> -                                chip_ver);
> +                       mb->chip_info = &rtl8365mb_chip_info_8367s;
>                         break;
>                 default:
> -                       dev_err(priv->dev, "unrecognized switch version (ver=0x%04x)",
> -                               chip_ver);
> +                       dev_err(priv->dev,
> +                               "unrecognized switch (id=0x%04x, ver=0x%04x)",
> +                               chip_id, chip_ver);
>                         return -ENODEV;
>                 }

With this patch, we now have a nice chip_info for each device. If we
group all of them in an array, we could iterate over them instead of
switching over chip_id/ver. In this case, adding a new variant is just
a matter of creating a new chip_info and adding to the array. When the
chip id/ver is only used inside a single chip_info, I don't know if we
should keep a macro declaring each value. For example,

#define RTL8365MB_CHIP_ID_8367S         0x6367
#define RTL8365MB_CHIP_VER_8367S        0x00A0
...
+static const struct rtl8365mb_chip_info rtl8365mb_chip_info_8367s = {
+       .name = "RTL8367S",
+       .chip_id = RTL8365MB_CHIP_ID_8367S,
+       .chip_ver = RTL8365MB_CHIP_VER_8367S,
+       .extints = {
+               { 6, 1, PHY_INTF(SGMII) | PHY_INTF(HSGMII) },
+               { 7, 2, PHY_INTF(MII) | PHY_INTF(TMII) | PHY_INTF(RMII) |
+                       PHY_INTF(RGMII) },
+               { /* sentinel */ }
+       },
+       .jam_table = rtl8365mb_init_jam_8365mb_vc,
+       .jam_size = ARRAY_SIZE(rtl8365mb_init_jam_8365mb_vc),
+};

seems to be as clear as:

+static const struct rtl8365mb_chip_info rtl8365mb_chip_info_8367s = {
+       .name = "RTL8367S",
+       .chip_id = 0x6367,
+       .chip_ver = 0x00A0,
+       .extints = {
+               { 6, 1, PHY_INTF(SGMII) | PHY_INTF(HSGMII) },
+               { 7, 2, PHY_INTF(MII) | PHY_INTF(TMII) | PHY_INTF(RMII) |
+                       PHY_INTF(RGMII) },
+               { /* sentinel */ }
+       },
+       .jam_table = rtl8365mb_init_jam_8365mb_vc,
+       .jam_size = ARRAY_SIZE(rtl8365mb_init_jam_8365mb_vc),
+};

but smaller and not spread over the source.

Regards,

Luiz

Re: [PATCH net-next 5/5] net: dsa: realtek: rtl8365mb: handle PHY interface modes correctly

[Alvin Šipraga]

On Tue, Jun 07, 2022 at 11:23:40AM -0300, Luiz Angelo Daros de Luca wrote:
> > From: Alvin Šipraga <alsi@bang-olufsen.dk>
> >
> > Realtek switches in the rtl8365mb family always have at least one port
> > with a so-called external interface, supporting PHY interface modes such
> > as RGMII or SGMII. The purpose of this patch is to improve the driver's
> > handling of these ports.
> >
> > A new struct rtl8365mb_chip_info is introduced. A static instance of
> > this struct is added for each supported switch, which is distinguished
> > by its chip ID and version. Embedded in each chip_info struct is an
> > array of struct rtl8365mb_extint, describing the external interfaces
> > available. This is more specific than the old rtl8365mb_extint_port_map,
> > which was only valid for switches with up to 6 ports.
> >
> > The struct rtl8365mb_extint also contains a bitmask of supported PHY
> > interface modes, which allows the driver to distinguish which ports
> > support RGMII. This corrects a previous mistake in the driver whereby it
> > was assumed that any port with an external interface supports RGMII.
> > This is not actually the case: for example, the RTL8367S has two
> > external interfaces, only the second of which supports RGMII. The first
> > supports only SGMII and HSGMII. This new design will make it easier to
> > add support for other interface modes.
> >
> > Finally, rtl8365mb_phylink_get_caps() is fixed up to return supported
> > capabilities based on the external interface properties described above.
> > This allows for ports with an external interface to be treated as DSA
> > user ports, and for ports with an internal PHY to be treated as DSA CPU
> > ports.
> 
> That's a nice patch. But while dealing with ext interfaces, wouldn't
> it be nice to also add
> a mask for user ports? We could easily validate if a declared dsa port
> really exists.

At best this will be useful to emit a warning for the device tree author.
Can you see any other benefit?

> 
> ...
> 
> > @@ -1997,33 +2122,27 @@ static int rtl8365mb_detect(struct realtek_priv *priv)
> >         case RTL8365MB_CHIP_ID_8365MB_VC:
> >                 switch (chip_ver) {
> >                 case RTL8365MB_CHIP_VER_8365MB_VC:
> > -                       dev_info(priv->dev,
> > -                                "found an RTL8365MB-VC switch (ver=0x%04x)\n",
> > -                                chip_ver);
> > +                       mb->chip_info = &rtl8365mb_chip_info_8365mb_vc;
> >                         break;
> >                 case RTL8365MB_CHIP_VER_8367RB_VB:
> > -                       dev_info(priv->dev,
> > -                                "found an RTL8367RB-VB switch (ver=0x%04x)\n",
> > -                                chip_ver);
> > +                       mb->chip_info = &rtl8365mb_chip_info_8367rb_vb;
> >                         break;
> >                 case RTL8365MB_CHIP_VER_8367S:
> > -                       dev_info(priv->dev,
> > -                                "found an RTL8367S switch (ver=0x%04x)\n",
> > -                                chip_ver);
> > +                       mb->chip_info = &rtl8365mb_chip_info_8367s;
> >                         break;
> >                 default:
> > -                       dev_err(priv->dev, "unrecognized switch version (ver=0x%04x)",
> > -                               chip_ver);
> > +                       dev_err(priv->dev,
> > +                               "unrecognized switch (id=0x%04x, ver=0x%04x)",
> > +                               chip_id, chip_ver);
> >                         return -ENODEV;
> >                 }
> 
> With this patch, we now have a nice chip_info for each device. If we
> group all of them in an array, we could iterate over them instead of
> switching over chip_id/ver. In this case, adding a new variant is just
> a matter of creating a new chip_info and adding to the array. When the
> chip id/ver is only used inside a single chip_info, I don't know if we
> should keep a macro declaring each value. For example,
> 
> #define RTL8365MB_CHIP_ID_8367S         0x6367
> #define RTL8365MB_CHIP_VER_8367S        0x00A0
> ...
> +static const struct rtl8365mb_chip_info rtl8365mb_chip_info_8367s = {
> +       .name = "RTL8367S",
> +       .chip_id = RTL8365MB_CHIP_ID_8367S,
> +       .chip_ver = RTL8365MB_CHIP_VER_8367S,
> +       .extints = {
> +               { 6, 1, PHY_INTF(SGMII) | PHY_INTF(HSGMII) },
> +               { 7, 2, PHY_INTF(MII) | PHY_INTF(TMII) | PHY_INTF(RMII) |
> +                       PHY_INTF(RGMII) },
> +               { /* sentinel */ }
> +       },
> +       .jam_table = rtl8365mb_init_jam_8365mb_vc,
> +       .jam_size = ARRAY_SIZE(rtl8365mb_init_jam_8365mb_vc),
> +};
> 
> seems to be as clear as:
> 
> +static const struct rtl8365mb_chip_info rtl8365mb_chip_info_8367s = {
> +       .name = "RTL8367S",
> +       .chip_id = 0x6367,
> +       .chip_ver = 0x00A0,
> +       .extints = {
> +               { 6, 1, PHY_INTF(SGMII) | PHY_INTF(HSGMII) },
> +               { 7, 2, PHY_INTF(MII) | PHY_INTF(TMII) | PHY_INTF(RMII) |
> +                       PHY_INTF(RGMII) },
> +               { /* sentinel */ }
> +       },
> +       .jam_table = rtl8365mb_init_jam_8365mb_vc,
> +       .jam_size = ARRAY_SIZE(rtl8365mb_init_jam_8365mb_vc),
> +};
> 
> but smaller and not spread over the source.

Good idea! Albeit at the cost of one more level of indentation ;-)

I'll give it a go for v2.

Kind regards,
Alvin

Re: [PATCH net-next 5/5] net: dsa: realtek: rtl8365mb: handle PHY interface modes correctly

[Luiz Angelo Daros de Luca]

> > That's a nice patch. But while dealing with ext interfaces, wouldn't
> > it be nice to also add
> > a mask for user ports? We could easily validate if a declared dsa port
> > really exists.
>
> At best this will be useful to emit a warning for the device tree author.
> Can you see any other benefit?

No, that's it. It might avoid some headaches when someone simply
assumes that ports are sequential.
All models have holes in port sequences but it will get worse once we
support a variant like RTL8363SC that port_id starts at 2.

Regards,

Luiz

Re: [PATCH net-next 0/5] net: dsa: realtek: rtl8365mb: improve handling of PHY modes

[Alvin Šipraga]

On Mon, Jun 06, 2022 at 03:45:48PM +0200, Alvin Šipraga wrote:
> From: Alvin Šipraga <alsi@bang-olufsen.dk>
> 
> This series introduces some minor cleanup of the driver and improves the
> handling of PHY interface modes to break the assumption that CPU ports
> are always over an external interface, and the assumption that user
> ports are always using an internal PHY.

Please ignore this version of the series, it has a build issue due to incorrect
splitting of patches between net and net-next.

I think I will re-send it for net instead as it makes things much easier for
everybody involved.

> 
> Alvin Šipraga (5):
>   net: dsa: realtek: rtl8365mb: rename macro RTL8367RB -> RTL8367RB_VB
>   net: dsa: realtek: rtl8365mb: remove port_mask private data member
>   net: dsa: realtek: rtl8365mb: correct the max number of ports
>   net: dsa: realtek: rtl8365mb: remove learn_limit_max private data
>     member
>   net: dsa: realtek: rtl8365mb: handle PHY interface modes correctly
> 
>  drivers/net/dsa/realtek/rtl8365mb.c | 268 ++++++++++++++++++++--------
>  1 file changed, 189 insertions(+), 79 deletions(-)
> 
> -- 
> 2.36.0
>