From: Thomas Wismer <thomas@wismer.xyz>
To: Andrew Lunn <andrew@lunn.ch>
Cc: Conor Dooley <conor@kernel.org>,
Oleksij Rempel <o.rempel@pengutronix.de>,
Kory Maincent <kory.maincent@bootlin.com>,
Andrew Lunn <andrew+netdev@lunn.ch>,
"David S. Miller" <davem@davemloft.net>,
Eric Dumazet <edumazet@google.com>,
Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
Rob Herring <robh@kernel.org>,
Krzysztof Kozlowski <krzk+dt@kernel.org>,
Conor Dooley <conor+dt@kernel.org>,
Thomas Wismer <thomas.wismer@scs.ch>,
netdev@vger.kernel.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH 3/3] dt-bindings: pse-pd: ti,tps23881: Add TPS23881B
Date: Thu, 9 Oct 2025 22:33:02 +0200 [thread overview]
Message-ID: <20251009223302.306e036a@pavilion> (raw)
In-Reply-To: <e14c6932-efc9-4bf2-a07b-6bbb56d7ffbd@lunn.ch>
Am Wed, 8 Oct 2025 14:38:52 +0200
schrieb Andrew Lunn <andrew@lunn.ch>:
> On Wed, Oct 08, 2025 at 01:52:43PM +0200, Thomas Wismer wrote:
> > Am Tue, 7 Oct 2025 21:40:03 +0100
> > schrieb Conor Dooley <conor@kernel.org>:
> >
> > > On Sat, Oct 04, 2025 at 08:03:53PM +0200, Thomas Wismer wrote:
> > > > From: Thomas Wismer <thomas.wismer@scs.ch>
> > > >
> > > > 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.
next prev parent reply other threads:[~2025-10-09 20:50 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-10-04 18:03 [PATCH 0/3] net: pse-pd: Add TPS23881B support Thomas Wismer
2025-10-04 18:03 ` [PATCH 1/3] net: pse-pd: tps23881: Fix current measurement scaling Thomas Wismer
2025-10-06 12:50 ` Kory Maincent
2025-10-06 20:45 ` Thomas Wismer
2025-10-04 18:03 ` [PATCH 2/3] net: pse-pd: tps23881: Add support for TPS23881B Thomas Wismer
2025-10-06 13:05 ` Kory Maincent
2025-10-06 21:23 ` Thomas Wismer
2025-10-07 12:18 ` Kory Maincent
2025-10-04 18:03 ` [PATCH 3/3] dt-bindings: pse-pd: ti,tps23881: Add TPS23881B Thomas Wismer
2025-10-07 20:40 ` Conor Dooley
2025-10-08 11:52 ` Thomas Wismer
2025-10-08 12:38 ` Andrew Lunn
2025-10-09 20:33 ` Thomas Wismer [this message]
2025-10-09 21:43 ` Andrew Lunn
2025-10-10 14:49 ` Conor Dooley
2025-10-10 16:54 ` Andrew Lunn
2025-10-10 14:49 ` Conor Dooley
2025-10-06 12:59 ` [PATCH 0/3] net: pse-pd: Add TPS23881B support Kory Maincent
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=20251009223302.306e036a@pavilion \
--to=thomas@wismer.xyz \
--cc=andrew+netdev@lunn.ch \
--cc=andrew@lunn.ch \
--cc=conor+dt@kernel.org \
--cc=conor@kernel.org \
--cc=davem@davemloft.net \
--cc=devicetree@vger.kernel.org \
--cc=edumazet@google.com \
--cc=kory.maincent@bootlin.com \
--cc=krzk+dt@kernel.org \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=o.rempel@pengutronix.de \
--cc=pabeni@redhat.com \
--cc=robh@kernel.org \
--cc=thomas.wismer@scs.ch \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.