linux-kernel - Re: [PATCH 1/3] dt-bindings: mfd: Add power-button option for TI TPS6594 PMIC

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAKMwjwQOBE651A-5VVjwcv5TspO2eNZfgwWzMpTTWxhR3nGKUw@mail.gmail.com>
Date: Mon, 2 Jun 2025 09:07:09 -0400
From: Job Sava <jsava@...ticallink.com>
To: Krzysztof Kozlowski <krzk@...nel.org>
Cc: Lee Jones <lee@...nel.org>, Rob Herring <robh@...nel.org>, 
	Krzysztof Kozlowski <krzk+dt@...nel.org>, Conor Dooley <conor+dt@...nel.org>, 
	Julien Panis <jpanis@...libre.com>, Dmitry Torokhov <dmitry.torokhov@...il.com>, 
	devicetree@...r.kernel.org, linux-kernel@...r.kernel.org, 
	linux-input@...r.kernel.org, jcormier@...ticallink.com
Subject: Re: [PATCH 1/3] dt-bindings: mfd: Add power-button option for TI
 TPS6594 PMIC

On Thu, May 29, 2025 at 5:26 AM Krzysztof Kozlowski <krzk@...nel.org> wrote:
>
> On Fri, May 23, 2025 at 09:46:49AM GMT, Job Sava wrote:
> > On Wed, May 21, 2025 at 6:01 AM Krzysztof Kozlowski <krzk@...nel.org> wrote:
> > >
> > > On Tue, May 20, 2025 at 01:43:36PM GMT, Job Sava wrote:
> > > > The TPS6594 power-button option permits users to enter STANDBY or
> > > > ACTIVE state by a push, release, or short push button request.
> > > >
> > > > Signed-off-by: Job Sava <jsava@...ticallink.com>
> > > > ---
> > > >  Documentation/devicetree/bindings/mfd/ti,tps6594.yaml | 15 +++++++++++++++
> > > >  1 file changed, 15 insertions(+)
> > > >
> > > > diff --git a/Documentation/devicetree/bindings/mfd/ti,tps6594.yaml b/Documentation/devicetree/bindings/mfd/ti,tps6594.yaml
> > > > index 6341b6070366..a40808fd2747 100644
> > > > --- a/Documentation/devicetree/bindings/mfd/ti,tps6594.yaml
> > > > +++ b/Documentation/devicetree/bindings/mfd/ti,tps6594.yaml
> > > > @@ -37,6 +37,21 @@ properties:
> > > >        device on the SPMI bus, and the secondary PMICs are the target devices
> > > >        on the SPMI bus.
> > > >
> > > > +  ti,power-button:
> > > > +    type: boolean
> > > > +    description: |
> > > > +      Optional property that sets the EN/PB/VSENSE pin to be a
> > > > +      power-button.
> > > > +      TPS6594 has a multipurpose pin called EN/PB/VSENSE that can be either
> > > > +      1. EN in which case it functions as an enable pin.
> > > > +      2. VSENSE which compares the voltages and triggers an automatic
> > > > +      on/off request.
> > > > +      3. PB in which case it can be configured to trigger an interrupt
> > > > +      to the SoC.
> > > > +      ti,power-button reflects the last one of those options
> > > > +      where the board has a button wired to the pin and triggers
> > > > +      an interrupt on pressing it.
> > >
> > > Don't you need to handle two other cases as well? I assume you copied
> > > this from the other binding, but all three options are valid?
> > >
> > > Best regards,
> > > Krzysztof
> > >
> > Hello Krzysztof,
> >
> > Thank you for your response!
> >
> > I agree that the other two cases are valid options. However, for this
> > particular patch series, they may be out of scope. The primary goal of
> > this patch is to enable push-button functionality, rather than
> > addressing the VSENSE or EN modes.
>
> Binding should be complete, because if you design this as bool, it
> cannot be later changed to three-state (enum).
>
> I don't know if the EN and VSENSE modes are anyhow useful, maybe people
> interested in this hardware should say.
>
> Best regards,
> Krzysztof
>

Hi Krzysztof,

Thanks again for the feedback.

I modeled this binding after the TPS65219 PMIC, which uses a boolean
for ti,power-button, despite the same EN/PB/VSENSE options. Since this
patch only enables PB mode, I felt a boolean was appropriate and
consistent.

That said, if you think an enum is strongly preferred here, I’m happy
to rework it accordingly.

Best regards,
Job Sava