Re: [PATCH net-next v5 5/5] net: dsa: ks8995: Delete surplus driver

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] The transitional Kconfig symbol NET_DSA_KS8995 becomes invisible by removing its prompt string, causing it to be silently dropped during config migration and failing to enable the new driver.
- [High] The new ksz_spi driver fails to probe when instantiated via platform data (non-DT), breaking existing non-DT ks8995 users.
--

commit 8ed57f24bf56fd7cb6ebaef9e6fc435940681d6f
Author: Linus Walleij <linusw@kernel.org>

net: dsa: ks8995: Delete surplus driver

This commit deletes the old ks8995 driver since the Microchip ksz driver
now handles these switches. It leaves a stub in Kconfig to automatically
transition users to the new symbol when migrating their configurations.

> The Microchip ksz driver now handles all switches that the
> old driver was handling, but better.

[Severity: High]
Does the new ksz_spi driver support non-Device-Tree (platform data)
instantiations like the old ks8995 driver did?

Looking at ksz_spi_probe() in drivers/net/dsa/microchip/ksz_spi.c, it
aborts the probe when no match data is found:

	chip = device_get_match_data(ddev);
	if (!chip)
		return -EINVAL;

For non-DT instantiations, this relies on the driver_data field in
the SPI ID table. However, ksz_spi_ids[] in the same file does not define
driver_data mappings for any chip entries:

static const struct spi_device_id ksz_spi_ids[] = {
	{ "ks8995" },
	{ "ksz8463" },

This means bus fallback matching will provide a NULL chip data structure,
causing the probe to unconditionally fail with -EINVAL. Could this break
support for existing non-Device-Tree users migrating to the new driver?

> diff --git a/drivers/net/dsa/Kconfig b/drivers/net/dsa/Kconfig
> index e704ab702c189..f2a48c5bfc12b 100644
> --- a/drivers/net/dsa/Kconfig
> +++ b/drivers/net/dsa/Kconfig
> @@ -98,13 +98,15 @@ config NET_DSA_RZN1_A5PSW
>  	  RZ/N1 SoC.
>  
>  config NET_DSA_KS8995
> -	tristate "Micrel KS8995 family 5-ports 10/100 Ethernet switches"
> +	tristate
>  	depends on SPI

[Severity: High]
Does removing the prompt string make this symbol invisible to Kconfig?

Without a prompt or a default attribute, an invisible symbol unconditionally
evaluates to n. During config migration, such as when running make oldconfig,
the user's previous selection in .config would be ignored and dropped.

Consequently, the select NET_DSA_MICROCHIP_KSZ_SPI statement below would never
be triggered, causing users to silently lose switch functionality when upgrading
their kernels.

Would it be better to retain the prompt with an obsolete label or provide
a default fallback to retain the old value?

> -	depends on !NET_DSA_MICROCHIP_KSZ_SPI
> -	select NET_DSA_TAG_NONE
> +	select NET_DSA_MICROCHIP_KSZ_COMMON
> +	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://sashiko.dev/#/patchset/20260604-ks8995-to-ksz8-v5-0-98baeb45e665@kernel.org?part=5