From: netdev-bot+sashiko@kernel.org
To: linusw@kernel.org
Cc: woojung.huh@microchip.com, UNGLinuxDriver@microchip.com,
andrew@lunn.ch, olteanv@gmail.com, davem@davemloft.net,
edumazet@google.com, kuba@kernel.org, pabeni@redhat.com,
robh@kernel.org, krzk+dt@kernel.org, conor+dt@kernel.org,
marex@denx.de, horms@kernel.org, linux@armlinux.org.uk,
nb@tipi-net.de, netdev@vger.kernel.org,
devicetree@vger.kernel.org
Subject: Re: [PATCH net-next v11 4/4] net: dsa: ks8995: Delete surplus driver
Date: Thu, 10 Sep 2026 20:02:03 +0000 [thread overview]
Message-ID: <178907052301.219967.24777314580254394@kernel.org> (raw)
In-Reply-To: <20260909-ks8995-to-ksz8-v11-4-0e04411a559d@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] Incomplete DT-binding transition: after drivers/net/dsa/ks8995.c
is deleted, the compatibles "micrel,ks8995", "micrel,ksz8795" and…
--
net: dsa: ks8995: Delete surplus driver
The old ks8995 DSA driver is removed because the Microchip KSZ driver now
handles the KS(Z)8995XA, and the NET_DSA_KS8995 Kconfig symbol is turned
into a transitional stub that selects the KSZ SPI driver instead. The two
in-tree device trees using "micrel,ks8995" are said to keep working with
the replacement driver.
> diff --git a/drivers/net/dsa/Kconfig b/drivers/net/dsa/Kconfig
> index e309e4c1ee3a..55a9714033a6 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 = n
> - 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.
[ ... ]
> diff --git a/drivers/net/dsa/ks8995.c b/drivers/net/dsa/ks8995.c
> deleted file mode 100644
> index 77d8b842693c..000000000000
> --- a/drivers/net/dsa/ks8995.c
> +++ /dev/null
> @@ -1,857 +0,0 @@
[ ... ]
> -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 device tree bindings move over together with the driver here?
After this deletion, "micrel,ks8995", "micrel,ksz8795" and "micrel,ksz8864"
are documented only in
Documentation/devicetree/bindings/net/dsa/micrel,ks8995.yaml, which was
written for the driver being removed:
properties:
compatible:
enum:
- micrel,ks8995
- micrel,ksz8795
- micrel,ksz8864
reg: ...
reset-gpios: ...
...
unevaluatedProperties: false
The driver that now matches those compatibles is
drivers/net/dsa/microchip/ksz_spi.c, whose ksz_dt_ids still carries:
{
.compatible = "micrel,ks8995",
.data = &ksz_switch_chips[KSZ8995XA]
},
ksz_spi_probe() does dev->irq = spi->irq, and ksz_mdio_register() looks up
an "mdio" child node and an "mdio-parent-bus" phandle. Those properties are
described in microchip,ksz.yaml but rejected by micrel,ks8995.yaml because of
unevaluatedProperties: false. Does that mean a node using the legacy
compatible with interrupts or an mdio child node now fails dt_binding_check?
In the other direction, microchip,ksz.yaml gained microchip,ksz8995xa but
lists none of the three micrel,* strings, so the two in-tree nodes named in
the commit message, ethernet-switch@0 in
arch/arm/boot/dts/intel/ixp/intel-ixp42x-linksys-wrv54g.dts and in
arch/arm/boot/dts/intel/ixp/intel-ixp42x-actiontec-mi424wr.dtsi, cannot be
validated against the binding of the driver that handles them. Would it make
sense to fold the legacy compatibles into microchip,ksz.yaml, marking them
deprecated as appropriate?
One more detail in the surviving schema: the description states
The chip itself is managed over SPI, but all the
PHYs need to be accessed from an external MDIO channel.
while the chip data for KSZ8995XA in drivers/net/dsa/microchip/ksz_common.c
declares
.internal_phy = {true, true, true, true, false},
Is that sentence still accurate for the replacement driver?
--
Sashiko AI review · https://netdev-ai.bots.linux.dev/sashiko/#/patchset/20260909-ks8995-to-ksz8-v11-0-0e04411a559d%40kernel.org
next prev parent reply other threads:[~2026-09-10 20:02 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-09 17:00 [PATCH net-next v11 0/4] net: dsa: microchip: Add support for KSZ8995XA/KS8995XA Linus Walleij
2026-09-09 17:00 ` [PATCH net-next v11 1/4] dt-bindings: net: dsa: microchip: Add KSZ8995XA Linus Walleij
2026-09-10 20:01 ` netdev-bot+sashiko
2026-09-10 20:29 ` Linus Walleij
2026-09-09 17:00 ` [PATCH net-next v11 2/4] net: dsa: tag_ks8995: Add the KS8995 tag handling Linus Walleij
2026-09-10 20:01 ` netdev-bot+sashiko
2026-09-09 17:00 ` [PATCH net-next v11 3/4] net: dsa: microchip: Support Microchip KSZ8995XA / KS8995XA Linus Walleij
2026-09-10 20:02 ` netdev-bot+sashiko
2026-09-10 20:53 ` Linus Walleij
2026-09-09 17:00 ` [PATCH net-next v11 4/4] net: dsa: ks8995: Delete surplus driver Linus Walleij
2026-09-10 20:02 ` netdev-bot+sashiko [this message]
2026-09-10 20:40 ` Linus Walleij
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=178907052301.219967.24777314580254394@kernel.org \
--to=netdev-bot+sashiko@kernel.org \
--cc=UNGLinuxDriver@microchip.com \
--cc=andrew@lunn.ch \
--cc=conor+dt@kernel.org \
--cc=davem@davemloft.net \
--cc=devicetree@vger.kernel.org \
--cc=edumazet@google.com \
--cc=horms@kernel.org \
--cc=krzk+dt@kernel.org \
--cc=kuba@kernel.org \
--cc=linusw@kernel.org \
--cc=linux@armlinux.org.uk \
--cc=marex@denx.de \
--cc=nb@tipi-net.de \
--cc=netdev@vger.kernel.org \
--cc=olteanv@gmail.com \
--cc=pabeni@redhat.com \
--cc=robh@kernel.org \
--cc=woojung.huh@microchip.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox