Re: [net-next,v8,5/5] 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: 0 · Low: 1

- [Low] After this patch drivers/net/dsa/microchip/ksz_spi.c (ksz_dt_ids,
  lines 236-249) is the only implementation of the compatibles…

--

net: dsa: ks8995: Delete surplus driver

This removes drivers/net/dsa/ks8995.c and its Makefile entry, since the
Microchip ksz driver now covers the same switches. NET_DSA_KS8995 is kept
in Kconfig as a transitional symbol that selects the ksz SPI driver.

> diff --git a/drivers/net/dsa/Kconfig b/drivers/net/dsa/Kconfig
> index 68fb175cc36ab..55a9714033a6f 100644
> --- a/drivers/net/dsa/Kconfig
> +++ b/drivers/net/dsa/Kconfig
> @@ -110,11 +110,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
> -	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.
>  
>  config NET_DSA_SMSC_LAN9303
>  	tristate

[ ... ]

> diff --git a/drivers/net/dsa/ks8995.c b/drivers/net/dsa/ks8995.c
> deleted file mode 100644
> index 77d8b842693c1..0000000000000
> --- a/drivers/net/dsa/ks8995.c
> +++ /dev/null

[ ... ]

> -static const struct of_device_id ks8995_spi_of_match[] = {
> -	{ .compatible = "micrel,ks8995" },
> -	{ .compatible = "micrel,ksz8864" },
> -	{ .compatible = "micrel,ksz8795" },
> -	{ },
> -};
> -MODULE_DEVICE_TABLE(of, ks8995_spi_of_match);

[Severity: Low]
Should the devicetree binding be folded over as well when these three
compatibles move to the ksz driver?

After the deletion, ksz_dt_ids in drivers/net/dsa/microchip/ksz_spi.c is the
only implementation of micrel,ks8995, micrel,ksz8795 and micrel,ksz8864:

	{
		.compatible = "micrel,ksz8864",
		.data = &ksz_switch_chips[KSZ8864]
	},
	...
	{
		.compatible = "micrel,ks8995",
		.data = &ksz_switch_chips[KSZ8995XA]
	},

But the only schema selecting those strings is
Documentation/devicetree/bindings/net/dsa/micrel,ks8995.yaml, which was
written for the deleted driver and ends with:

	unevaluatedProperties: false

allowing only compatible, reg, reset-gpios, the dsa.yaml ethernet-ports and
spi-peripheral-props.

The surviving driver parses more than that for these chips. For example
ksz_mdio_register() in drivers/net/dsa/microchip/ksz_common.c does:

	mdio_np = of_get_child_by_name(dev->dev->of_node, "mdio");

and ksz_switch_register() looks at wakeup-source,
microchip,synclko-125/synclko-disable, microchip,pme-active-high,
micrel,fiber-mode and interrupts. Those properties are described only in
Documentation/devicetree/bindings/net/dsa/microchip,ksz.yaml, whose
compatible enum contains no micrel-prefixed string.

So a board that uses compatible = "micrel,ks8995" and adds an mdio child
node binds fine at runtime, but would dt_binding_check/dtbs_check reject it,
with no schema left that can describe it? Would it make sense to add the
micrel aliases to microchip,ksz.yaml (deprecated) or cross-reference it from
micrel,ks8995.yaml?

Both in-tree users, arch/arm/boot/dts/intel/ixp/intel-ixp42x-actiontec-mi424wr.dtsi
and arch/arm/boot/dts/intel/ixp/intel-ixp42x-linksys-wrv54g.dts, only use
compatible, reg, spi-max-frequency and ethernet-ports, so nothing fails
today.

Related, is this part of the micrel,ks8995.yaml description still accurate
now that the ksz driver handles the chip?

  The chip itself is managed over SPI, but all the PHYs need to be accessed
  from an external MDIO channel.

ksz_switch_chips[KSZ8995XA] in ksz_common.c declares

	.internal_phy = {true, true, true, true, false},

and the ksz driver can register an internal MDIO bus for those PHYs, so the
sentence reads like a property of the removed driver rather than of the
hardware.

-- 
Sashiko AI review · https://netdev-ai.bots.linux.dev/sashiko/#/patchset/20260831-ks8995-to-ksz8-v8-0-fd1dbb2b76e8%40kernel.org