From: sashiko-bot@kernel.org
To: "Linus Walleij" <linusw@kernel.org>
Cc: conor+dt@kernel.org, devicetree@vger.kernel.org, robh@kernel.org
Subject: Re: [PATCH net-next v12 3/4] net: dsa: microchip: Support Microchip KSZ8995XA / KS8995XA
Date: Sat, 12 Sep 2026 09:10:26 +0000 [thread overview]
Message-ID: <20260912091027.691EA1F00893@smtp.kernel.org> (raw)
In-Reply-To: <20260911-ks8995-to-ksz8-v12-3-5c3422d0d72e@kernel.org>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] The PHY soft reset loop in `ksz8_reset_switch` unconditionally issues a soft reset and polls for it to self-clear on all ports, including the CPU port which lacks an internal PHY. This risks causing a probe timeout on the KSZ8995XA if the reserved register latches the bit.
--
commit d45e85fe8d15053b235725e1e75c154fee3c35c3
Author: Linus Walleij <linusw@kernel.org>
net: dsa: microchip: Support Microchip KSZ8995XA / KS8995XA
This commit adds support for the Microchip KSZ8995XA switch to the KSZ driver.
It introduces hardware detection, a dedicated PHY soft reset workaround for
this older switch, and configures the switch for its specific legacy features.
> diff --git a/drivers/net/dsa/microchip/ksz8.c b/drivers/net/dsa/microchip/ksz8.c
> index 941ae9f66f70b..4acce01ca0631 100644
> --- a/drivers/net/dsa/microchip/ksz8.c
> +++ b/drivers/net/dsa/microchip/ksz8.c
[ ... ]
> @@ -253,7 +255,35 @@ static int ksz8463_reset_switch(struct ksz_device *dev)
>
> static int ksz8_reset_switch(struct ksz_device *dev)
> {
> - if (ksz_is_ksz88x3(dev)) {
> + if (ksz_is_ksz8995xa(dev)) {
> + unsigned int port, reg, val;
> + int ret;
> +
> + /* The KSZ8995XA switch itself cannot be reset by software, but
> + * often boot loaders have fun with ports, so reset them. This
> + * reset bit is self-clearing.
> + */
> + for (port = 0; port < dev->info->port_cnt; port++) {
> + ret = ksz_prmw8(dev, port, REG_PORT_STATUS_3,
> + PORT_PHY_SOFT_RESET,
> + PORT_PHY_SOFT_RESET);
> + if (ret)
> + return ret;
> + }
[Severity: Medium]
Does this loop incorrectly include the MAC-only CPU port?
Since dev->info->port_cnt is 5 for the KSZ8995XA, this iterates over ports
0 through 4. Port 4 is the CPU port, which does not have an internal PHY.
Does writing PORT_PHY_SOFT_RESET to REG_PORT_STATUS_3 on the CPU port write
to a reserved register?
> +
> + /* IEEE 802.3 allows up to 500 ms for a PHY reset. */
> + for (port = 0; port < dev->info->port_cnt; port++) {
> + reg = dev->dev_ops->get_port_addr(port, REG_PORT_STATUS_3);
> + ret = regmap_read_poll_timeout(ksz_regmap_8(dev), reg, val,
> + !(val & PORT_PHY_SOFT_RESET),
> + 1000, 600000);
> + if (ret)
> + return ret;
> + }
[Severity: Medium]
Will this polling loop timeout on the CPU port if the hardware latches the
written bit?
Since the CPU port lacks the PHY logic to execute the reset and self-clear
the bit, it might hang indefinitely and fail the probe with -ETIMEDOUT.
Should this loop (and the write loop above) be restricted to
dev->phy_port_cnt instead of dev->info->port_cnt?
[ ... ]
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260911-ks8995-to-ksz8-v12-0-5c3422d0d72e@kernel.org?part=3
next prev parent reply other threads:[~2026-09-12 9:10 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-11 9:09 [PATCH net-next v12 0/4] net: dsa: microchip: Add support for KSZ8995XA/KS8995XA Linus Walleij
2026-09-11 9:09 ` [PATCH net-next v12 1/4] dt-bindings: net: dsa: microchip: Add KSZ8995XA Linus Walleij
2026-09-11 11:43 ` Nicolai Buchwitz
2026-09-11 9:09 ` [PATCH net-next v12 2/4] net: dsa: tag_ks8995: Add the KS8995 tag handling Linus Walleij
2026-09-11 11:46 ` Nicolai Buchwitz
2026-09-11 9:09 ` [PATCH net-next v12 3/4] net: dsa: microchip: Support Microchip KSZ8995XA / KS8995XA Linus Walleij
2026-09-11 12:11 ` Nicolai Buchwitz
2026-09-12 9:10 ` sashiko-bot [this message]
2026-09-11 9:09 ` [PATCH net-next v12 4/4] net: dsa: ks8995: Delete surplus driver 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=20260912091027.691EA1F00893@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=linusw@kernel.org \
--cc=robh@kernel.org \
--cc=sashiko-reviews@lists.linux.dev \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.