linux-kernel - Re: [PATCH net-next v1 1/2] dt-bindings: net: dsa: Add KSZ8567 switch 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 for Android: free password hash cracker in your pocket

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

Date: Thu, 25 Jan 2024 11:57:19 +0200
From: Vladimir Oltean <olteanv@...il.com>
To: Conor Dooley <conor@...nel.org>
Cc: Philippe Schenker <dev@...henker.ch>, netdev@...r.kernel.org,
	Paolo Abeni <pabeni@...hat.com>, Conor Dooley <conor+dt@...nel.org>,
	Woojung Huh <woojung.huh@...rochip.com>,
	linux-kernel@...r.kernel.org, UNGLinuxDriver@...rochip.com,
	Marek Vasut <marex@...x.de>,
	Florian Fainelli <f.fainelli@...il.com>, devicetree@...r.kernel.org,
	Eric Dumazet <edumazet@...gle.com>,
	"David S . Miller" <davem@...emloft.net>,
	Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
	Jakub Kicinski <kuba@...nel.org>, Andrew Lunn <andrew@...n.ch>,
	Rob Herring <robh+dt@...nel.org>
Subject: Re: [PATCH net-next v1 1/2] dt-bindings: net: dsa: Add KSZ8567
 switch support

Hi Conor,

On Tue, Jan 23, 2024 at 06:37:55PM +0000, Conor Dooley wrote:
> On Tue, Jan 23, 2024 at 06:30:16PM +0100, Philippe Schenker wrote:
> > > > Hi Conor, Thanks for your message!
> > > > 
> > > > I need the compatible to make sure the correct ID of the switch is
> > > > being set in the driver as well as its features.
> > > 
> > > Are the features of this switch such that a driver for another ksz
> > > switch would not work (even in a limited capacity) with the 8567?
> > > Things like the register map changing or some feature being removed
> > > are
> > > examples of why it may not work.
> > 
> > Yes the ksz dsa driver is made so that it checks the ID of the attached
> > chip and refuses to work if it doesn't match. [1]
> 
> That sounds counter productive to be honest. Why does the driver not
> trust that the dt is correct? I saw this recently in some IIO drivers,
> but it was shot down for this sort of reason.

If the hardware provides device ID registers, what is the best practice
in reconciling them with the compatible string?

I see 2 extreme cases. Ethernet PHY devices seem to blindly trust the
PHY ID from the "ethernet-phy-idXXXX.XXXX" compatible string, and phylib
won't read the PHY ID from the standard MDIO registers when this is present.
Whereas PCI seems to completely disregard the vendor ID and device ID
from the "pciXXXX,XXXX" compatible string of function OF nodes. Both
these subsystems have the "compatible" string optional.

I could see an advantage in using a precise device ID in the compatible
string, rather than just one from which the _location_ of the device ID
can be deduced, because the precise compatible string allows for much
finer grained static analysis in the schema for the device. In case of a
switch, that is the number of ports, supported interface modes for each
port, etc. With an imprecise device ID, you don't know what you really
get until you boot the board.

> And despite the email, I have nothing to do with these switches, I am
> just a sucker that signed up to review dt-bindings...

Same here, just a sucker with some switches and not many clues about
other things :)