Re: [PATCH net-next v15 4/4] net: dsa: ks8995: Delete surplus driver

[netdev-bot+sashiko@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential
issue(s) to consider:

Critical: 0 · High: 0 · Medium: 1 · Low: 0

- [Medium] Commit message claims the two in-tree boards "continue to be
  supported by the replacement driver without regressions", but the…

--

net: dsa: ks8995: Delete surplus driver

This removes drivers/net/dsa/ks8995.c and its Makefile entry, leaving
NET_DSA_KS8995 behind in Kconfig as a transitional stub that selects the
Microchip KSZ SPI driver instead.

> diff --git a/drivers/net/dsa/Kconfig b/drivers/net/dsa/Kconfig
> index e3d88f41fecf7..fe8cd5338fda5 100644
> --- a/drivers/net/dsa/Kconfig
> +++ b/drivers/net/dsa/Kconfig
> @@ -112,11 +112,13 @@ config NET_DSA_RZN1_A5PSW
>  config NET_DSA_KS8995
>  	tristate "Micrel KS8995 family 5-ports 10/100 Ethernet switches"
>  	depends on SPI
> -	depends on NET_DSA_MICROCHIP_KSZ_SPI = n
> -	select NET_DSA_TAG_NONE
> +	select NET_DSA_MICROCHIP_KSZ_COMMON
> +	select NET_DSA_MICROCHIP_KSZ_SPI

[Severity: Medium]
The commit message says the two in-tree boards "both use KS8995XA hardware
and continue to be supported by the replacement driver without regressions".
Is that description accurate with respect to tagging and port isolation?

The deleted driver used no switch tag and did not program the switch at all:

drivers/net/dsa/ks8995.c:
	static enum
	dsa_tag_protocol ks8995_get_tag_protocol(struct dsa_switch *ds, ...)
	{
		/* This switch actually uses the 6 byte KS8995 protocol */
		return DSA_TAG_PROTO_NONE;
	}

	static int ks8995_setup(struct dsa_switch *ds)
	{
		return 0;
	}

The replacement path for the same "micrel,ks8995" compatible reports a
different protocol and enables special tagging:

drivers/net/dsa/microchip/ksz8.c:ksz8995xa_get_tag_protocol()
	return DSA_TAG_PROTO_KS8995;

drivers/net/dsa/microchip/ksz8.c:ksz8_setup()
	if (ksz_is_ksz8995xa(dev))
		ksz_cfg(dev, REG_SW_CTRL_9, SW_SPECIAL_TAG, true);

ksz8_port_setup() also programs per-port tag insert/remove and restricts
standalone user ports to the upstream port via ksz8_cfg_port_member() with
member = BIT(dsa_upstream_port(ds, port)).

So on intel-ixp42x-linksys-wrv54g.dts and
intel-ixp42x-actiontec-mi424wr.dtsi, frames on the CPU MII link now carry
the switch tag, and user ports are isolated until a bridge is created, so
LAN-to-LAN hardware forwarding no longer happens by default.

Until this patch users could stay on the old behaviour because the two
symbols were mutually exclusive:

	depends on NET_DSA_MICROCHIP_KSZ_SPI = n

Removing that line makes the switch to the new tagging and port semantics
unavoidable. Could the commit message describe this behaviour change rather
than stating there are no regressions, given it also notes that the MA and E
variants were never verified with the replacement driver?

> +	select NET_DSA_MICROCHIP_KSZ_SPI
>  	help
> -	  This driver supports the Micrel KS8995 family of 10/100 Mbit ethernet
> -	  switches, managed over SPI.
> +	  This is a transitional option for users who had NET_DSA_KS8995
> +	  enabled. It automatically enables the new NET_DSA_MICROCHIP_KSZ_SPI
> +	  driver which supersedes it. This option will be removed in a future
> +	  kernel release.

[ ... ]

-- 
Sashiko AI review · https://netdev-ai.bots.linux.dev/sashiko/#/patchset/20260916-ks8995-to-ksz8-v15-0-8825ff5fd4be%40kernel.org