linux-input.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Andreas Kemnade <andreas@kemnade.info>
To: Krzysztof Kozlowski <krzk@kernel.org>
Cc: Lee Jones <lee@kernel.org>, Rob Herring <robh@kernel.org>,
	Krzysztof Kozlowski <krzk+dt@kernel.org>,
	Conor Dooley <conor+dt@kernel.org>,
	Dmitry Torokhov <dmitry.torokhov@gmail.com>,
	Tony Lindgren <tony@atomide.com>,
	Kevin Hilman <khilman@kernel.org>,
	devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
	linux-input@vger.kernel.org, linux-omap@vger.kernel.org
Subject: Re: [PATCH 1/3] dt-bindings: mfd: twl: enable power button also for twl603x
Date: Tue, 21 Oct 2025 18:36:24 +0200	[thread overview]
Message-ID: <20251021183624.6fde0a15@kemnade.info> (raw)
In-Reply-To: <beabb9f7-fcf4-4c1d-a259-6c48e82fbcf5@kernel.org>

On Tue, 21 Oct 2025 11:58:49 +0200
Krzysztof Kozlowski <krzk@kernel.org> wrote:

> On 21/10/2025 10:45, Andreas Kemnade wrote:
> > On Tue, 21 Oct 2025 09:10:28 +0200
> > Krzysztof Kozlowski <krzk@kernel.org> wrote:
> >   
> >> On 20/10/2025 14:31, akemnade@kernel.org wrote:  
> >>> From: Andreas Kemnade <andreas@kemnade.info>
> >>>
> >>> TWL603x has also a power button, so add the corresponding subnode.    
> >>
> >> No, we don't add subnodes just because there is a power button. This
> >> needs broader explanation, see also my further comment.
> >>  
> > Hmm, what is the general pattern to follow if a mfd device has some
> > functionality which depends on some optional external components?  
> 
> Please describe it better - how these nodes depend on external
> component? The power button logic/IC is in this device always. It is not
> optional.
>
The power button logic is always there, yes, but it depends on an optional
actual mechanical button connected to a pad of this device, which is
not always there. The logic will not work if I just put my finger on the PMIC,
but it will work if there is a mechanical button which I can press connected to
the PMIC.

> > The might be a power button connected to it or not. I find it ugly
> > to have non-existent stuff in the system.
> > In general, yes I understand the argument against the subnode.
> >   
> >>>
> >>> Signed-off-by: Andreas Kemnade <andreas@kemnade.info>
> >>> ---
> >>>  Documentation/devicetree/bindings/mfd/ti,twl.yaml | 40 ++++++++++++++++++-----
> >>>  1 file changed, 32 insertions(+), 8 deletions(-)
> >>>
> >>> diff --git a/Documentation/devicetree/bindings/mfd/ti,twl.yaml b/Documentation/devicetree/bindings/mfd/ti,twl.yaml
> >>> index 776b04e182cb2..3527fee32cb07 100644
> >>> --- a/Documentation/devicetree/bindings/mfd/ti,twl.yaml
> >>> +++ b/Documentation/devicetree/bindings/mfd/ti,twl.yaml
> >>> @@ -55,6 +55,15 @@ allOf:
> >>>  
> >>>          gpadc: false
> >>>  
> >>> +        pwrbutton:
> >>> +          properties:
> >>> +            compatible:
> >>> +              const: ti,twl4030-pwrbutton
> >>> +            interrupts:
> >>> +              items:
> >>> +                - items:
> >>> +                    const: 8    
> >>
> >> What is the point of defining const interrupts? If they are const, then
> >> it is implied by compatible and defined in the driver.
> >>
> >> Anyway, double items does not look right here. This is an odd syntax.
> >>  
> > Quoting Rob:
> > As 'interrupts' is a matrix, this needs to be:
> > 
> > interrupts:
> >   items:
> >     - items:
> >         - const: 8
> > 
> > https://lore.kernel.org/linux-omap/20240318150750.GA4000895-robh@kernel.org/  
> 
> 
> OK, this answers second part but I don't understand why even having this
> in DT. If this is fixed, should be implied by the compatible?
> 
correct, they do not need to come from DT. The same is true for all
subnodes of the twl[46]03X. I just followed the usual
pattern there, which is of course not recommended for new designs.

Regards,
Andreas

  reply	other threads:[~2025-10-21 16:36 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-10-20 12:31 [PATCH 0/3] mfd: twl603x: add power button akemnade
2025-10-20 12:31 ` [PATCH 1/3] dt-bindings: mfd: twl: enable power button also for twl603x akemnade
2025-10-21  7:10   ` Krzysztof Kozlowski
2025-10-21  8:45     ` Andreas Kemnade
2025-10-21  9:58       ` Krzysztof Kozlowski
2025-10-21 16:36         ` Andreas Kemnade [this message]
2025-10-21 17:18           ` Krzysztof Kozlowski
2025-10-22  8:55             ` Andreas Kemnade
2025-10-20 12:31 ` [PATCH 2/3] Input: add TWL603x power button akemnade
2025-10-21  7:07   ` Krzysztof Kozlowski
2025-10-21 17:58   ` Dmitry Torokhov
2025-10-22 12:44     ` Andreas Kemnade
2025-10-22 18:48       ` Dmitry Torokhov
2025-10-23 18:56         ` Andreas Kemnade
2025-10-20 12:32 ` [PATCH 3/3] ARM: dts: ti/omap: omap4-epson-embt2ws: add powerbutton akemnade

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=20251021183624.6fde0a15@kemnade.info \
    --to=andreas@kemnade.info \
    --cc=conor+dt@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=dmitry.torokhov@gmail.com \
    --cc=khilman@kernel.org \
    --cc=krzk+dt@kernel.org \
    --cc=krzk@kernel.org \
    --cc=lee@kernel.org \
    --cc=linux-input@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-omap@vger.kernel.org \
    --cc=robh@kernel.org \
    --cc=tony@atomide.com \
    /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;
as well as URLs for NNTP newsgroup(s).