Re: [PATCH 3/3] dt-bindings: pse-pd: ti,tps23881: Add TPS23881B
From: Thomas Wismer <hidden>
Date: 2025-10-09 20:50:18
Also in:
linux-devicetree, lkml
Am Wed, 8 Oct 2025 14:38:52 +0200 schrieb Andrew Lunn [off-list ref]:
On Wed, Oct 08, 2025 at 01:52:43PM +0200, Thomas Wismer wrote:quoted
Am Tue, 7 Oct 2025 21:40:03 +0100 schrieb Conor Dooley [off-list ref]:quoted
On Sat, Oct 04, 2025 at 08:03:53PM +0200, Thomas Wismer wrote:quoted
From: Thomas Wismer <redacted> Add the TPS23881B I2C power sourcing equipment controller to the list of supported devices.Missing an explanation for why a fallback compatible is not suitable here. Seems like it is, if the only difference is that the firmware is not required to be refreshed, provided that loading the non-B firmware on a B device would not be problematic.Loading the non-B firmware on a B device is indeed problematic. I'll append the following paragraph to the patch when reposting it after the current merge window has closed.Is it possible to ask the device what it is?
Yes, the devices allow the silicon revision to be read, which would enable a driver to correctly handle the case distinctions.
If you can, maybe you don't even need a new compatible, just load the appropriate firmware depending on what the device says it is.
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). Is there any best practice when to use auto-detection with I2C devices? 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.