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
Subject: Re: [PATCH net-next v4 5/9] net: dsa: realtek: rtl8365mb: set and get vlan 4k for family D
Date: Tue, 13 Oct 2026 01:08:30 +0000 [thread overview]
Message-ID: <179185371034.434549.16480732640712379008@kernel.org> (raw)
In-Reply-To: <41c9a735-0688-4932-b0b2-5c41ecbc6699@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] Commit message wording (rejected by baseline, kept only because
requires_validation=true).
--
net: dsa: realtek: rtl8365mb: set and get vlan 4k for family D
The commit gives family D its own two-word CVLAN (VLAN4k) table layout
in rtl8365mb_vlan_4k_read() and rtl8365mb_vlan_4k_write(). It narrows
FID to 2 bits and drops the priority/meter fields. It also forces both
the IVL_EN and SVLAN_CHK_IVL_SVL bits to 1 on write.
> Reusing the three-word family C layout unconditionally means the third
> word is read from and written back to the register that holds it on
> family C, but does not exist as a distinct table word on family D's
> die; whatever data happens to be there gets folded into member/untag
> bits [10:8] on read, and re-written on every read-modify-write cycle
> in rtl8365mb_vlan_4k_port_set(). Give family D its own two-word
> pack/unpack instead.
[Severity: Low]
This isn't a bug, but could this paragraph say that the new path can't
run yet at this commit?
Every entry in rtl8365mb_chip_infos is still tagged RTL8365MB_FAMILY_C,
and rtl8365mb_detect() only matches entries in that table. So
rtl8365mb_get_family() never returns RTL8365MB_FAMILY_D here, and this
check is always false:
bool is_d = rtl8365mb_get_family(priv) == RTL8365MB_FAMILY_D;
The first FAMILY_D chip entry appears later, in "add support for
RTL8367S-VB". Until then, the is_d branches in rtl8365mb_vlan_4k_read()
and rtl8365mb_vlan_4k_write() are unreachable.
Would a short note on this help readers who see the paragraph above and
take it as a description of current runtime behavior?
--
Sashiko AI review · https://netdev-ai.bots.linux.dev/sashiko/#/patchset/38872e6f-1264-4a93-9f81-8212173e909d%40yahoo.com
next prev parent reply other threads:[~2026-10-13 1:08 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <38872e6f-1264-4a93-9f81-8212173e909d.ref@yahoo.com>
2026-10-12 0:08 ` [PATCH net-next v4 0/9] net: dsa: realtek: rtl8365mb: add support for RTL8367S-VB Mieczyslaw Nalewaj
2026-10-12 0:09 ` [PATCH net-next v4 1/9] dt-bindings: net: dsa: realtek: add RTL8367S-V Mieczyslaw Nalewaj
2026-10-12 9:31 ` Linus Walleij
2026-10-12 14:15 ` Mieczyslaw Nalewaj
2026-10-13 1:08 ` netdev-bot+sashiko
2026-10-12 0:10 ` [PATCH net-next v4 2/9] net: dsa: realtek: rtl8365mb: add chip family infrastructure Mieczyslaw Nalewaj
2026-10-12 0:11 ` [PATCH net-next v4 3/9] net: dsa: realtek: rtl8365mb: set speed for family D Mieczyslaw Nalewaj
2026-10-12 0:12 ` [PATCH net-next v4 4/9] net: dsa: realtek: rtl8365mb: set RGMII mode " Mieczyslaw Nalewaj
2026-10-13 1:08 ` netdev-bot+sashiko
2026-10-12 0:12 ` [PATCH net-next v4 5/9] net: dsa: realtek: rtl8365mb: set and get vlan 4k " Mieczyslaw Nalewaj
2026-10-13 1:08 ` netdev-bot+sashiko [this message]
2026-10-12 0:13 ` [PATCH net-next v4 6/9] net: dsa: realtek: rtl8365mb: use raw VID for PVID on " Mieczyslaw Nalewaj
2026-10-12 0:14 ` [PATCH net-next v4 7/9] net: dsa: realtek: rtl8365mb: add family D SDS13 PCS support Mieczyslaw Nalewaj
2026-10-13 1:08 ` netdev-bot+sashiko
2026-10-12 0:15 ` [PATCH net-next v4 8/9] net: dsa: realtek: rtl8365mb: re-latch the family D SerDes Mieczyslaw Nalewaj
2026-10-13 1:08 ` netdev-bot+sashiko
2026-10-12 0:16 ` [PATCH net-next v4 9/9] net: dsa: realtek: rtl8365mb: add support for RTL8367S-VB Mieczyslaw Nalewaj
2026-10-13 1:08 ` netdev-bot+sashiko
2026-10-13 8:49 ` Mieczyslaw Nalewaj
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=179185371034.434549.16480732640712379008@kernel.org \
--to=netdev-bot+sashiko@kernel.org \
--cc=andrew@lunn.ch \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=kuba@kernel.org \
--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