From: "Alvin Šipraga" <alvin.sipraga@analog.com>
To: Oleksij Rempel <o.rempel@pengutronix.de>
Cc: "David S. Miller" <davem@davemloft.net>,
Eric Dumazet <edumazet@kernel.org>,
Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
Simon Horman <horms@kernel.org>,
Linus Walleij <linusw@kernel.org>,
Luiz Angelo Daros de Luca <luizluca@gmail.com>,
Andrew Lunn <andrew@lunn.ch>, Vladimir Oltean <olteanv@gmail.com>,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
kernel@pengutronix.de
Subject: Re: [PATCH net-next v2 05/10] net: dsa: realtek: rtl8365mb: describe the ports of each chip
Date: Thu, 12 Nov 2026 16:08:47 +0100 [thread overview]
Message-ID: <avXUEaiSnKsO705y@analog.com> (raw)
In-Reply-To: <20261112-rtl8365mb-dcb-ingress-v2-5-f8e6fbdf8c99@pengutronix.de>
On Thu, Nov 12, 2026 at 09:37:48AM +0100, Oleksij Rempel wrote:
> Record which ports each chip has, report one more than its highest
> port to DSA as the port count, and reject a devicetree port the chip
> does not have. Lower the family maximum to 8 to match.
>
> Commit ca5ecd4246d4 ("net: dsa: realtek: rtl8365mb: correct the max
> number of ports") raised the port count of all chips to 11, but no
> supported chip has a port above 7.
>
> Since commit 51a4a22301b0 ("net: dsa: realtek: rtl8365mb: use dsa
> helpers for port iteration"), setup also programs unused ports, so
> every probe writes per-port registers of ports 8..10. Their learn-limit
> writes go to 0x0A28..0x0A2A, above the learn-limit registers of ports
> 0..7. We have not seen a visible effect from these writes.
I'm not quite sure what the point of the patch is (sorry, maybe it's
clear later in the series, but I didn't get that far yet). Was the setup
of nonexistent ports clobbering some other registers?
Of course in practice none of the supported chips are >8 so there's
nothing technically wrong with this patch, but just wondering.
Also in the blamed commit there was:
-/* RTL8370MB and RTL8310SR, possibly suportable by this driver, have 10 ports */
-#define RTL8365MB_MAX_NUM_PORTS 10
+#define RTL8365MB_MAX_NUM_PORTS 11
So maybe it needs bumping in the future if support is added for those
chips. That's why I'm wondering if you saw something off?
>
> Signed-off-by: Oleksij Rempel <o.rempel@pengutronix.de>
> ---
> Changes in v2:
> - New in v2. The QoS patches after it handle ports 0..7 only.
> ---
> drivers/net/dsa/realtek/rtl8365mb_main.c | 28 ++++++++++++++++++++++++++--
> 1 file changed, 26 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/dsa/realtek/rtl8365mb_main.c b/drivers/net/dsa/realtek/rtl8365mb_main.c
> index da06f952a053d1497647a2c6f15a861fc21860f9..1e6cdc61f6bd3b3f74e422dbbcfdcb67cc0532a7 100644
> --- a/drivers/net/dsa/realtek/rtl8365mb_main.c
> +++ b/drivers/net/dsa/realtek/rtl8365mb_main.c
> @@ -115,7 +115,7 @@
> #define RTL8365MB_PHYADDRMAX 7
> #define RTL8365MB_NUM_PHYREGS 32
> #define RTL8365MB_PHYREGMAX (RTL8365MB_NUM_PHYREGS - 1)
> -#define RTL8365MB_MAX_NUM_PORTS 11
> +#define RTL8365MB_MAX_NUM_PORTS 8
> /* Valid for the whole family except RTL8370B, which has 4160 entries.
> * RTL8370B is mentioned in vendor code but it might not even belong
> * to the same RTL8367C family.
> @@ -707,6 +707,7 @@ struct rtl8365mb_extint {
> * @name: human-readable chip name
> * @chip_id: chip identifier
> * @chip_ver: chip silicon revision
> + * @port_mask: ports the chip has
> * @extints: available external interfaces
> * @jam_table: chip-specific initialization jam table
> * @jam_size: size of the chip's jam table
> @@ -719,6 +720,7 @@ struct rtl8365mb_chip_info {
> const char *name;
> u32 chip_id;
> u32 chip_ver;
> + u32 port_mask;
> const struct rtl8365mb_extint extints[RTL8365MB_MAX_NUM_EXTINTS];
> const struct rtl8365mb_jam_tbl_entry *jam_table;
> size_t jam_size;
> @@ -726,11 +728,20 @@ struct rtl8365mb_chip_info {
>
> /* Chip info for each supported switch in the family */
> #define PHY_INTF(_mode) (RTL8365MB_PHY_INTERFACE_MODE_ ## _mode)
> +#define PORT_MASK(_m) \
> + ((_m) + \
> + BUILD_BUG_ON_ZERO((_m) & ~GENMASK(RTL8365MB_MAX_NUM_PORTS - 1, 0)))
> +
> +/* Copper ports are 0..3 on the RTL8365MB-VC and 0..4 on the others. Extension
> + * interfaces are port 6 on the VC and ports 6 and 7 on the others, as the
> + * extints rows show.
> + */
> static const struct rtl8365mb_chip_info rtl8365mb_chip_infos[] = {
> {
> .name = "RTL8365MB-VC",
> .chip_id = 0x6367,
> .chip_ver = 0x0040,
> + .port_mask = PORT_MASK(GENMASK(3, 0) | BIT(6)),
> .extints = {
> { 6, 1, PHY_INTF(MII) | PHY_INTF(TMII) |
> PHY_INTF(RMII) | PHY_INTF(RGMII) },
> @@ -742,6 +753,7 @@ static const struct rtl8365mb_chip_info rtl8365mb_chip_infos[] = {
> .name = "RTL8367S",
> .chip_id = 0x6367,
> .chip_ver = 0x00A0,
> + .port_mask = PORT_MASK(GENMASK(4, 0) | BIT(6) | BIT(7)),
> .extints = {
> { 6, 1, PHY_INTF(SGMII) | PHY_INTF(HSGMII) },
> { 7, 2, PHY_INTF(MII) | PHY_INTF(TMII) |
> @@ -754,6 +766,7 @@ static const struct rtl8365mb_chip_info rtl8365mb_chip_infos[] = {
> .name = "RTL8367SB",
> .chip_id = 0x6367,
> .chip_ver = 0x0010,
> + .port_mask = PORT_MASK(GENMASK(4, 0) | BIT(6) | BIT(7)),
> .extints = {
> { 6, 1, PHY_INTF(MII) | PHY_INTF(TMII) |
> PHY_INTF(RMII) | PHY_INTF(RGMII) |
> @@ -768,6 +781,7 @@ static const struct rtl8365mb_chip_info rtl8365mb_chip_infos[] = {
> .name = "RTL8367RB-VB",
> .chip_id = 0x6367,
> .chip_ver = 0x0020,
> + .port_mask = PORT_MASK(GENMASK(4, 0) | BIT(6) | BIT(7)),
> .extints = {
> { 6, 1, PHY_INTF(MII) | PHY_INTF(TMII) |
> PHY_INTF(RMII) | PHY_INTF(RGMII) },
> @@ -3140,6 +3154,16 @@ static int rtl8365mb_setup(struct dsa_switch *ds)
> dev_info(priv->dev, "no interrupt support\n");
>
> dsa_switch_for_each_port(dp, ds) {
> + if (dsa_port_is_unused(dp))
> + continue;
You can use dsa_switch_for_each_available_port() here.
> +
> + if (!(mb->chip_info->port_mask & BIT(dp->index))) {
> + dev_err(priv->dev, "port %d does not exist on %s\n",
> + dp->index, mb->chip_info->name);
> + ret = -EINVAL;
> + goto out_teardown_irq;
> + }
> +
> /* Cascading (DSA links) is not supported yet.
> * Historically, the driver has always been broken
> * without a dedicated CPU port because CPU tagging
> @@ -3349,7 +3373,7 @@ static int rtl8365mb_detect(struct realtek_priv *priv)
>
> dev_info(priv->dev, "found an %s switch\n", mb->chip_info->name);
>
> - priv->num_ports = RTL8365MB_MAX_NUM_PORTS;
> + priv->num_ports = fls(mb->chip_info->port_mask);
> mb->priv = priv;
> mb->cpu.trap_port = RTL8365MB_MAX_NUM_PORTS;
> mb->cpu.insert = RTL8365MB_CPU_INSERT_TO_ALL;
>
> --
> 2.47.3
>
next prev parent reply other threads:[~2026-11-12 15:09 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-11-12 8:37 [PATCH net-next v2 00/10] net: dsa: realtek: rtl8365mb: DCB ingress QoS offload Oleksij Rempel
2026-11-12 8:37 ` [PATCH net-next v2 01/10] net: ieee8021q: print traffic type and queue count with %u Oleksij Rempel
2026-11-12 8:37 ` [PATCH net-next v2 02/10] net: ieee8021q: add pcp_to_tt() Oleksij Rempel
2026-11-12 8:37 ` [PATCH net-next v2 03/10] net: ieee8021q: clarify the tt_to_tc() traffic-class mapping Oleksij Rempel
2026-11-12 8:37 ` [PATCH net-next v2 04/10] net: ieee8021q: add tt_to_pcp() Oleksij Rempel
2026-11-12 8:37 ` [PATCH net-next v2 05/10] net: dsa: realtek: rtl8365mb: describe the ports of each chip Oleksij Rempel
2026-11-12 15:08 ` Alvin Šipraga [this message]
2026-11-12 8:37 ` [PATCH net-next v2 06/10] net: dsa: realtek: rtl8365mb: store the egress queue count per chip Oleksij Rempel
2026-11-12 8:37 ` [PATCH net-next v2 07/10] net: dsa: realtek: rtl8365mb: add QoS baseline and DCB default prio Oleksij Rempel
2026-11-12 8:37 ` [PATCH net-next v2 08/10] net: dsa: realtek: rtl8365mb: program the PCP of untagged frames Oleksij Rempel
2026-11-12 8:37 ` [PATCH net-next v2 09/10] net: dsa: realtek: rtl8365mb: offload DCB apptrust Oleksij Rempel
2026-11-12 8:37 ` [PATCH net-next v2 10/10] net: dsa: realtek: rtl8365mb: report the DCB DSCP-to-priority map Oleksij Rempel
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=avXUEaiSnKsO705y@analog.com \
--to=alvin.sipraga@analog.com \
--cc=andrew@lunn.ch \
--cc=davem@davemloft.net \
--cc=edumazet@kernel.org \
--cc=horms@kernel.org \
--cc=kernel@pengutronix.de \
--cc=kuba@kernel.org \
--cc=linusw@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=luizluca@gmail.com \
--cc=netdev@vger.kernel.org \
--cc=o.rempel@pengutronix.de \
--cc=olteanv@gmail.com \
--cc=pabeni@redhat.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox