Re: [PATCH net-next v11 3/4] net: dsa: microchip: Support Microchip KSZ8995XA / KS8995XA

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] Hardware Reset Timeout: `ksz8_reset_switch()` erroneously applies a PHY reset to all ports, including the CPU port which lacks an internal PHY.
--

commit 80bf0b7a0236c83f85f86b7cc57ef97388c5c06c
Author: Linus Walleij <linusw@kernel.org>

net: dsa: microchip: Support Microchip KSZ8995XA / KS8995XA

This commit adds support for the Microchip KSZ8995XA switch in the KSZ
driver. It implements hardware detection, MAC operations, and specific
PHY reset and initialization sequences required for this legacy device.

> diff --git a/drivers/net/dsa/microchip/ksz8.c b/drivers/net/dsa/microchip/ksz8.c
> --- 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;
> +		}
> +
> +		/* 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]
Could this result in a timeout regression that fails switch initialization?

Both loops in ksz8_reset_switch() iterate over all ports up to
dev->info->port_cnt, which is 5 for the KSZ8995XA, thereby including the
CPU port. Since the CPU port lacks an internal PHY, writing to its
REG_PORT_STATUS_3 targets an undefined or reserved register.

If the hardware latches the written bit or does not return 0 when read
back, the regmap_read_poll_timeout() call will hit its 600ms timeout
and return -ETIMEDOUT, entirely aborting the setup sequence.

Should these loops iterate up to dev->phy_port_cnt instead to avoid
resetting non-existent PHYs?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260909-ks8995-to-ksz8-v11-0-0e04411a559d@kernel.org?part=3