netdev - Re: [PATCH net-next v2 2/4] net: dsa: ks8955: Delete KSZ8864 and KSZ8795 support

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <CAD++jL=bVWWbgBezv6DTscK9122u0hOCa3Ooq58ziYr6h-CJDA@mail.gmail.com>
Date: Tue, 20 Jan 2026 00:26:13 +0100
From: Linus Walleij <linusw@...nel.org>
To: Vladimir Oltean <olteanv@...il.com>
Cc: Andrew Lunn <andrew@...n.ch>, "David S. Miller" <davem@...emloft.net>, 
	Eric Dumazet <edumazet@...gle.com>, Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>, 
	Woojung Huh <woojung.huh@...rochip.com>, UNGLinuxDriver@...rochip.com, 
	netdev@...r.kernel.org
Subject: Re: [PATCH net-next v2 2/4] net: dsa: ks8955: Delete KSZ8864 and
 KSZ8795 support

On Mon, Jan 19, 2026 at 10:58 PM Vladimir Oltean <olteanv@...il.com> wrote:
> On Mon, Jan 19, 2026 at 03:30:06PM +0100, Linus Walleij wrote:

> > After studying the datasheets for a bit, I can conclude that
> > the register maps for the two KSZ variants explicitly said to
> > be supported by this driver are fully supported by the newer
> > Micrel KSZ driver, including full VLAN support and a different
> > custom tag than what the KS8995 is using.
> >
> > Delete this support, users should be using the KSZ driver
> > CONFIG_NET_DSA_MICROCHIP_KSZ_SPI and any new device trees should
> > use:
> > micrel,ksz8864 -> microchip,ksz8864
> > micrel,ksz8795 -> microchip,ksz8795
>
> So the binding changes you've done to Documentation/devicetree/bindings/net/micrel-ks8995.txt
> in commit a0f29a07b654 ("dt-bindings: dsa: Rewrite Micrel KS8995 in schema")
> were apparently backwards-compatible. But this isn't - you're offering
> no forward path for existing device trees.

There is theoretically no contract that Linux has to respond to
all compatible strings listed in a DT binding document, but yeah it
would be nice to not screw things up for any potential users.

> IMO, even if nobody cares about these compatible strings (given that the
> "PHY" driver dates from 2016 and the KSZ DSA driver has supported these
> chips since 2019), IMO it's pretty hard to sell a loss of hardware support
> in a patch set targeted to 'net'.
>
> Does it make more sense to retarget the patches to 'net-next', drop
> the Fixes: tags and to somehow mark the driver as "experimental", to set
> the expectations about the fact that it's still under development and
> many things aren't how they should be?

I was thinking actually adding the micrel,* strings to the ksz driver
in this patch, or as a separate patch and mark them for backward
compatibility. But maybe that also need to qualify as non-fixes?

I can surely drop the Fixes: tags, mark experimental and perhaps also
put the revised tag patches on top to be safe, if we think this is
the best approach.

I did grep around, there are no users for the bindings in the in-kernel
trees or in OpenWrt. But who knows what it out there.

Yours,
Linus Walleij