mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: netdev-bot+sashiko@kernel.org
To: namiltd@yahoo.com
Cc: linusw@kernel.org, andrew@lunn.ch, olteanv@gmail.com,
	kuba@kernel.org, davem@davemloft.net, edumazet@google.com,
	pabeni@redhat.com, linux@armlinux.org.uk, luizluca@gmail.com,
	maxime.chevallier@bootlin.com, netdev@vger.kernel.org,
	linux-kernel@vger.kernel.org, alvin.sipraga@analog.com,
	gusfmora@gmail.com, kuncy7@gmail.com, fabianotassotti@gmail.com,
	gabonpivovich@gmail.com, contact@c127.dev
Subject: Re: [PATCH net-next v9 02/11] net: dsa: realtek: rtl8365mb: add chip family infrastructure
Date: Mon, 09 Nov 2026 08:52:41 +0000	[thread overview]
Message-ID: <179421436161.994134.8843393412347553629@kernel.org> (raw)
In-Reply-To: <310bca10-e082-4d0a-a645-42fd4e58d2a6@yahoo.com>

Thank you for your contribution! Sashiko AI review found more severe
issue(s) in other patches of this series. This mail is only an FYI, in case
you want to address the nit picks below when you respin.

Low priority / nit picks for your consideration:

- [Low] This patch leaves a stale comment in rtl8365mb_switch_init()
  (drivers/net/dsa/realtek/rtl8365mb_main.c).

--

net: dsa: realtek: rtl8365mb: add chip family infrastructure

This commit adds enum rtl8365mb_family and struct rtl8365mb_family_info.
The family id, port count and init jam table now live in the family
info, which struct rtl8365mb_chip_info points to, and all existing chips
use the RTL8365MB_FAMILY_C instance. rtl8365mb_detect() now takes
num_ports from the family info.

> diff --git a/drivers/net/dsa/realtek/rtl8365mb_main.c b/drivers/net/dsa/realtek/rtl8365mb_main.c
> index da06f952a053d..b500c8404c24b 100644
> --- a/drivers/net/dsa/realtek/rtl8365mb_main.c
> +++ b/drivers/net/dsa/realtek/rtl8365mb_main.c

[ ... ]

> @@ -702,14 +705,20 @@ struct rtl8365mb_extint {
>  	unsigned int supported_interfaces;
>  };
>  
> +static const struct rtl8365mb_family_info rtl8365mb_family_c = {
> +	.family = RTL8365MB_FAMILY_C,
> +	.num_ports = RTL8365MB_C_MAX_NUM_PORTS,
> +	.jam_table = rtl8365mb_init_jam_8365mb_vc,
> +	.jam_size = ARRAY_SIZE(rtl8365mb_init_jam_8365mb_vc),
> +};
> +
>  /**
>   * struct rtl8365mb_chip_info - static chip-specific info
>   * @name: human-readable chip name
>   * @chip_id: chip identifier
>   * @chip_ver: chip silicon revision
> + * @family_info: data shared by all chips of the same family
>   * @extints: available external interfaces
> - * @jam_table: chip-specific initialization jam table
> - * @jam_size: size of the chip's jam table

[ ... ]

> @@ -3036,17 +3048,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;
> +	const struct rtl8365mb_family_info *fi;
>  	int ret;
>  	int i;
>  
> -	ci = mb->chip_info;
> +	fi = mb->chip_info->family_info;
>  
>  	/* Do any chip-specific init jam before getting to the common stuff */
> -	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 (fi->jam_table) {
> +		for (i = 0; i < fi->jam_size; i++) {
> +			ret = regmap_write(priv->map, fi->jam_table[i].reg,
> +					   fi->jam_table[i].val);

[Severity: Low]
This isn't a bug, but should this comment in rtl8365mb_switch_init() be
updated?

The jam table no longer comes from struct rtl8365mb_chip_info. It now
comes from mb->chip_info->family_info, and the new kernel-doc describes
@family_info as "data shared by all chips of the same family".

The comment still says "chip-specific init jam", though. No later patch in
the series changes it. At the end of the series both rtl8365mb_family_c
and rtl8365mb_family_d point to the same rtl8365mb_init_jam_8365mb_vc
table.

Would something like "family-specific init jam" fit better?

>  			if (ret)
>  				return ret;
>  		}

[ ... ]

<br>

-- 
Sashiko AI review · https://netdev-ai.bots.linux.dev/sashiko/#/patchset/9b73858d-fc09-4988-8bab-fd7b88db9412%40yahoo.com

  parent reply	other threads:[~2026-11-09  8:52 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <9b73858d-fc09-4988-8bab-fd7b88db9412.ref@yahoo.com>
2026-11-08  8:04 ` [PATCH net-next v9 00/11] net: dsa: realtek: rtl8365mb: add support for RTL8367S-VB Mieczyslaw Nalewaj
2026-11-08  8:05   ` [PATCH net-next v9 01/11] dt-bindings: net: dsa: realtek: add RTL8367S-VB Mieczyslaw Nalewaj
2026-11-08  8:06   ` [PATCH net-next v9 02/11] net: dsa: realtek: rtl8365mb: add chip family infrastructure Mieczyslaw Nalewaj
2026-11-08 14:20     ` Linus Walleij
2026-11-09  8:52     ` netdev-bot+sashiko [this message]
2026-11-08  8:07   ` [PATCH net-next v9 03/11] net: dsa: realtek: rtl8365mb: set speed for family D Mieczyslaw Nalewaj
2026-11-08  8:08   ` [PATCH net-next v9 04/11] net: dsa: realtek: rtl8365mb: set RGMII mode " Mieczyslaw Nalewaj
2026-11-09  8:52     ` netdev-bot+sashiko
2026-11-08  8:09   ` [PATCH net-next v9 05/11] net: dsa: realtek: rtl8365mb: set and get vlan 4k " Mieczyslaw Nalewaj
2026-11-08  8:10   ` [PATCH net-next v9 06/11] net: dsa: realtek: rtl8365mb: use raw VID for PVID on " Mieczyslaw Nalewaj
2026-11-08  8:11   ` [PATCH net-next v9 07/11] net: dsa: realtek: rtl8365mb: add family D SDS13 PCS support Mieczyslaw Nalewaj
2026-11-09  8:52     ` netdev-bot+sashiko
2026-11-08  8:11   ` [PATCH net-next v9 08/11] net: dsa: realtek: rtl8365mb: re-latch the family D SerDes Mieczyslaw Nalewaj
2026-11-08 19:13     ` Johan Alvarado
2026-11-08 20:53       ` Mieczyslaw Nalewaj
2026-11-08  8:12   ` [PATCH net-next v9 09/11] net: dsa: realtek: rtl8365mb: refactor L2 MAC handling Mieczyslaw Nalewaj
2026-11-08  8:13   ` [PATCH net-next v9 10/11] net: dsa: realtek: rtl8365mb: make L2/LUT access work on family D Mieczyslaw Nalewaj
2026-11-09  8:52     ` netdev-bot+sashiko
2026-11-08  8:14   ` [PATCH net-next v9 11/11] net: dsa: realtek: rtl8365mb: add support for RTL8367S-VB Mieczyslaw Nalewaj
2026-11-08 14:21     ` Linus Walleij

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=179421436161.994134.8843393412347553629@kernel.org \
    --to=netdev-bot+sashiko@kernel.org \
    --cc=alvin.sipraga@analog.com \
    --cc=andrew@lunn.ch \
    --cc=contact@c127.dev \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=fabianotassotti@gmail.com \
    --cc=gabonpivovich@gmail.com \
    --cc=gusfmora@gmail.com \
    --cc=kuba@kernel.org \
    --cc=kuncy7@gmail.com \
    --cc=linusw@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@armlinux.org.uk \
    --cc=luizluca@gmail.com \
    --cc=maxime.chevallier@bootlin.com \
    --cc=namiltd@yahoo.com \
    --cc=netdev@vger.kernel.org \
    --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®