mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
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
> 

  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

all inboxes | Powered by JetHome®