Re: [PATCH net-next v4 1/5] net: dsa: microchip: Add fallback Micrel compatibles

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] The Kconfig dependency `depends on !NET_DSA_MICROCHIP_KSZ_SPI` fails to prevent both drivers from being compiled as modules simultaneously, leaving the probe race unresolved.
- [High] Enforcing blanket mutual exclusion entirely disables the KS8995 driver when KSZ_SPI is enabled, breaking support for legacy `micrel,ks8995` (KS8995MA) hardware.
--

commit 5818edfd41b48a4993fc7bbca349bb17e8aeaa95
Author: Linus Walleij <linusw@kernel.org>

net: dsa: microchip: Add fallback Micrel compatibles

Because of forking paths when Micrel was acquired by Microchip,
two devices also exist with the micrel,* prefix bindings.
Add these to the KSZ SPI driver so users can use the more capable
driver.

Make the KS8995 driver mutually exclusive with this driver
to avoid probe races.

> diff --git a/drivers/net/dsa/Kconfig b/drivers/net/dsa/Kconfig
> index 4ab567c5bbafc..e704ab702c189 100644
> --- a/drivers/net/dsa/Kconfig
> +++ b/drivers/net/dsa/Kconfig
> @@ -100,6 +100,7 @@ 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

[Severity: High]
Does this correctly prevent both drivers from being built as modules?

In Kconfig, the logical NOT of a module (!m) evaluates to m. Since both
NET_DSA_KS8995 and NET_DSA_MICROCHIP_KSZ_SPI are tristate symbols, if
NET_DSA_MICROCHIP_KSZ_SPI is configured as a module (=m), the dependency
evaluates to m. This allows NET_DSA_KS8995 to also be built as a module.

Since both modules register identical device tree compatible strings, udev
will load both drivers concurrently, triggering the exact probe race this
was intended to fix. To correctly enforce strict mutual exclusivity, the
dependency should use the equality operator, such as:
depends on NET_DSA_MICROCHIP_KSZ_SPI = n

While this may be resolved in a later patch that deletes the old driver, this
patch introduces a race condition for modular builds.

[Severity: High]
Does making these mutually exclusive break support for legacy hardware that
the newer driver doesn't handle?

The legacy ks8995.c driver natively supports the original micrel,ks8995
switch chip (the KS8995MA). The newer ksz_spi.c driver does not support
the KS8995MA chip. By forcing NET_DSA_KS8995 to be mutually exclusive with
NET_DSA_MICROCHIP_KSZ_SPI, this patch unconditionally breaks network switch
support on boards relying on the legacy KS8995MA hardware when the new driver
is enabled.

Should the drivers be allowed to coexist to support their respective legacy
hardware, or should the new driver fully implement KS8995MA support before
the legacy driver is disabled?

>  	select NET_DSA_TAG_NONE
>  	help
>  	  This driver supports the Micrel KS8995 family of 10/100 Mbit ethernet

[ ... ]

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260603-ks8995-to-ksz8-v4-0-e15149ef21e7@kernel.org?part=1