From: Conor Dooley <conor@kernel.org>
To: Guenter Roeck <linux@roeck-us.net>
Cc: Potin Lai <potin.lai.pt@gmail.com>, Rob Herring <robh@kernel.org>,
Krzysztof Kozlowski <krzk+dt@kernel.org>,
Conor Dooley <conor+dt@kernel.org>,
Zev Weiss <zev@bewilderbeest.net>,
linux-hwmon@vger.kernel.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org,
Cosmo Chou <cosmo.chou@quantatw.com>,
Mike Hsieh <Mike_Hsieh@quantatw.com>,
Potin Lai <potin.lai@qunatatw.com>
Subject: Re: [PATCH 1/2] dt-bindings: hwmon: pmbus: ti,lm25066: add current limit properties
Date: Fri, 12 Jun 2026 22:13:55 +0100 [thread overview]
Message-ID: <20260612-sibling-battalion-453d3d239aaa@spud> (raw)
In-Reply-To: <059f9ce2-39f0-4553-909d-58585d46edd3@roeck-us.net>
[-- Attachment #1: Type: text/plain, Size: 3689 bytes --]
On Fri, Jun 12, 2026 at 10:19:14AM -0700, Guenter Roeck wrote:
> On 6/12/26 09:12, Conor Dooley wrote:
> > On Fri, Jun 12, 2026 at 05:10:38PM +0800, Potin Lai wrote:
> > > On Fri, Jun 12, 2026 at 1:27 AM Conor Dooley <conor@kernel.org> wrote:
> > > >
> > > > On Thu, Jun 11, 2026 at 05:58:44PM +0800, Potin Lai wrote:
> > > > > Add mutually exclusive 'ti,cl-smbus-high' and 'ti,cl-smbus-low' boolean
> > > > > properties to configure the device's Current Limit (CL) behavior using
> > > > > SMBus settings instead of physical pins.
> > > > >
> > > > > Signed-off-by: Potin Lai <potin.lai.pt@gmail.com>
> > > > > ---
> > > > > .../devicetree/bindings/hwmon/pmbus/ti,lm25066.yaml | 20 ++++++++++++++++++++
> > > > > 1 file changed, 20 insertions(+)
> > > > >
> > > > > diff --git a/Documentation/devicetree/bindings/hwmon/pmbus/ti,lm25066.yaml b/Documentation/devicetree/bindings/hwmon/pmbus/ti,lm25066.yaml
> > > > > index a20f140dc79a..95ea7c26dec2 100644
> > > > > --- a/Documentation/devicetree/bindings/hwmon/pmbus/ti,lm25066.yaml
> > > > > +++ b/Documentation/devicetree/bindings/hwmon/pmbus/ti,lm25066.yaml
> > > > > @@ -46,6 +46,26 @@ properties:
> > > > >
> > > > > additionalProperties: false
> > > > >
> > > > > + ti,cl-smbus-high:
> > > > > + description: |
> > > > > + Configure the Current Limit (CL) to use the SMBus high setting.
> > > > > + type: boolean
> > > > > +
> > > > > + ti,cl-smbus-low:
> > > > > + description: |
> > > > > + Configure the Current Limit (CL) to use the SMBus low setting.
> > > > > + type: boolean
> > > >
> > > > What's smbus specific about this? If the pin was connected to a GPIO,
> > > > you'd then need to have different properties or use these ones with an
> > > > inaccurate name.
> > > >
> > >
> > > The "smbus" in the property name was originally meant to indicate
> > > that the setting is configured via the internal register over the SMBus (I2C)
> > > interface, rather than physical pins.
> >
> > Right, but if you do it via the physical pins using a gpio, you still
> > need a way to say what limit is. The status quo only works if the limit
> > pin is tied high or low.
> >
>
> The physical pin is supposed to be connected to ground or left floating.
> It seems unlikely that anyone would ever have the idea of connecting it
> to a GPIO pin, and doing so would for sure mess up the driver because
> its state is only read in the probe function. The configuration here
Well yeah, "obviously" if someone wanted to use a GPIO the driver would
have to change to handle that - but probably not that much since it'd be
a static setting that could be done at probe.
I get that it may be unlikely, but it seems like a reasonable thing that
someone might want to do, and renaming the property to not exclude that
usecase seems to be "free".
> is for setting the limit range (scale) with a configuration register
> to override the configuration obtained from the external pin.
> Either case, even _if_ the CL pin is connected to a GPIO pin, the status
> of that pin would be read from the configuration register. A devicetree
This isn't true, I don't think, unless you're using GPIO hogs?
The GPIO state when linux comes up could be the reset value of the
controller, rather than the correct configuration. You'd need a way to
tell the driver what way to drive it.
> property is not needed for that. The properties are to _override_ the pin
> configuration, not to reflect it.
TL;DR, I think the removal of smbus from the property name (I'm not
asking for it to be taken out of the description) is reasonable.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
next prev parent reply other threads:[~2026-06-12 21:13 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-11 9:58 [PATCH 0/2] hwmon: (pmbus/lm25066) Support SMBus Current Limit configuration Potin Lai
2026-06-11 9:58 ` [PATCH 1/2] dt-bindings: hwmon: pmbus: ti,lm25066: add current limit properties Potin Lai
2026-06-11 10:05 ` sashiko-bot
2026-06-11 17:27 ` Conor Dooley
2026-06-12 9:10 ` Potin Lai
2026-06-12 16:12 ` Conor Dooley
2026-06-12 17:19 ` Guenter Roeck
2026-06-12 21:13 ` Conor Dooley [this message]
2026-06-11 9:58 ` [PATCH 2/2] hwmon: (pmbus/lm25066) add SMBus current limit configuration support Potin Lai
2026-06-11 10:10 ` sashiko-bot
2026-06-11 12:20 ` Guenter Roeck
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=20260612-sibling-battalion-453d3d239aaa@spud \
--to=conor@kernel.org \
--cc=Mike_Hsieh@quantatw.com \
--cc=conor+dt@kernel.org \
--cc=cosmo.chou@quantatw.com \
--cc=devicetree@vger.kernel.org \
--cc=krzk+dt@kernel.org \
--cc=linux-hwmon@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@roeck-us.net \
--cc=potin.lai.pt@gmail.com \
--cc=potin.lai@qunatatw.com \
--cc=robh@kernel.org \
--cc=zev@bewilderbeest.net \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox