linux-kernel - Re: [PATCH 3/3] dt-bindings: pse-pd: ti,tps23881: Add TPS23881B

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: <8395a77f-b3ae-4328-9acb-58c6ac00bf9e@lunn.ch>
Date: Thu, 9 Oct 2025 23:43:04 +0200
From: Andrew Lunn <andrew@...n.ch>
To: Thomas Wismer <thomas@...mer.xyz>
Cc: Conor Dooley <conor@...nel.org>,
	Oleksij Rempel <o.rempel@...gutronix.de>,
	Kory Maincent <kory.maincent@...tlin.com>,
	Andrew Lunn <andrew+netdev@...n.ch>,
	"David S. Miller" <davem@...emloft.net>,
	Eric Dumazet <edumazet@...gle.com>,
	Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>,
	Rob Herring <robh@...nel.org>,
	Krzysztof Kozlowski <krzk+dt@...nel.org>,
	Conor Dooley <conor+dt@...nel.org>,
	Thomas Wismer <thomas.wismer@....ch>, netdev@...r.kernel.org,
	devicetree@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 3/3] dt-bindings: pse-pd: ti,tps23881: Add TPS23881B

> When adapting the driver, I also considered an auto-detection mechanism.
> However, it felt safer to rely on the devicetree information than reading
> a silicon revision register, which has a totally different meaning on
> some other device. I have therefore decided to make the driver behaviour
> solely dependent on the devicetree information and to use the silicon
> revision only as a sanity check (as already implemented in the driver).

So if the silicon and the DT disagree, you get -ENODEV or similar?
That is what i would recommend, so that broken DT blobs get found by
the developer.

> Is there any best practice when to use auto-detection with I2C devices?

Not really. There are devices/drivers where the compatible is just
used to indicate where to find the ID register in the hardware,
nothing else. The ID register is then used by the driver to do the
right thing, we trust the silicon to describe itself. But things like
PHY devices have the ID in a well known location, so we actually don't
require a compatible, but if one is given, we use that instead of the
ID found in the silicon. So the exact opposite.

> Regardless of whether the driver queries the silicon revision, the B
> device declaration would look somehow strange to me with a driver having
> one single compatible, i.e. compatible = "ti,tps23881b", "ti,tps23881".
> The first one specifically names the hardware, the fallback is actually
> the name of its predecessor, which is strictly speaking not 100%
> compatible but required to have the driver loaded.

If it is not compatible, a fallback will not actually work, don't list
a fallback.

	Andrew