All of lore.kernel.org
 help / color / mirror / Atom feed
From: Daniel Thompson <danielt@kernel.org>
To: Roman Vivchar <rva333@protonmail.com>
Cc: Lee Jones <lee@kernel.org>, Jingoo Han <jingoohan1@gmail.com>,
	Pavel Machek <pavel@kernel.org>, Rob Herring <robh@kernel.org>,
	Krzysztof Kozlowski <krzk+dt@kernel.org>,
	Conor Dooley <conor+dt@kernel.org>, Helge Deller <deller@gmx.de>,
	dri-devel@lists.freedesktop.org, linux-leds@vger.kernel.org,
	devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
	linux-fbdev@vger.kernel.org
Subject: Re: [PATCH 1/2] dt-bindings: leds: backlight: add Kinetic KTD3137
Date: Tue, 3 Nov 2026 17:10:01 +0000	[thread overview]
Message-ID: <auoVaaZjcnRTj1S9@aspen.lan> (raw)
In-Reply-To: <CmvbeteAqxtpenZUmJ4dqRvXYjjDzTTDevRB4NUlN0WGLOUk0jwzt2C3ZtuZ3Eb2UwBDEPUWpu9biU1OOhKGWQITolX96cFXolBTMgSyh1c=@protonmail.com>

On Tue, Nov 03, 2026 at 03:21:45PM +0000, Roman Vivchar wrote:
> On Tuesday, November 3rd, 2026 at 4:42 PM, Daniel Thompson <danielt@kernel.org> wrote:
>
> > On Tue, Nov 03, 2026 at 02:34:02PM +0000, Roman Vivchar wrote:
> > > Hi Daniel,
> > >
> > > On Tuesday, November 3rd, 2026 at 4:05 PM, Daniel Thompson <danielt@kernel.org> wrote:
> > > > On Mon, Nov 02, 2026 at 09:58:48PM +0200, Roman Vivchar via B4 Relay wrote:
> > > > > +  led-max-microamp:
> > > > > +    minimum: 5000
> > > > > +    maximum: 29800
> > > > > +    default: 20200
> > > > > +
> > > > > +  vin-supply: true
> > > > > +
> > > > > +required:
> > > > > +  - compatible
> > > > > +  - reg
> > > > > +  - vin-supply
> > > >
> > > > Why is vin-supply required?
> > > >
> > >
> > > The chip cannot function without VIN power supply. Even if it's on the
> > > always-on power rail on certain board, there's always a chance it might be
> > > accidentally left disabled on the other. It's better to document supply in
> > > the bindings as far as I understand.
> >
> > You haven't just documented the binding, you have also made the property
> > mandatory by adding it to required.
> >
> > So what I am asking is why is this property listed as required. You
> > didn't implement the driver in a way that makes the supply mandatory.
>
> Not sure I follow.
>
> In the driver I've used devm_regulator_get_enable(), rather than _optional(),
> since my understanding is that the non-optional helper is a standard kernel
> API for required supplies (with regulator core warning and fallback to dummy
> regulator in case DT omits it).

That dummy fallback essentially makes it optional. On a board with an
always-on supply then there is no need to include vin-supply in the
DTB. The driver will work just fine without it.


> Do you suggest dropping vin-supply from required: ? On my board it's connected
> to an always-on supply, though I can't tell about others. I can proceed with
> this if the DT maintainers are okay with that.

Given your answers then, yes, vin-supply should not be in the required:
list (e.g. we don't want DT validation to fail for a DT that does not
include a vin-supply).


Daniel.

  reply	other threads:[~2026-11-03 17:10 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-11-02 19:58 [PATCH 0/2] backlight: add ktd3137 support Roman Vivchar via B4 Relay
2026-11-02 19:58 ` Roman Vivchar
2026-11-02 19:58 ` [PATCH 1/2] dt-bindings: leds: backlight: add Kinetic KTD3137 Roman Vivchar via B4 Relay
2026-11-02 19:58   ` Roman Vivchar
2026-11-02 20:09   ` sashiko-bot
2026-11-03 14:05   ` Daniel Thompson
2026-11-03 14:34     ` Roman Vivchar
2026-11-03 14:42       ` Daniel Thompson
2026-11-03 15:21         ` Roman Vivchar
2026-11-03 17:10           ` Daniel Thompson [this message]
2026-11-02 19:58 ` [PATCH 2/2] backlight: add ktd3137 support Roman Vivchar via B4 Relay
2026-11-02 19:58   ` Roman Vivchar
2026-11-02 20:18   ` sashiko-bot
2026-11-03 14:15   ` Daniel Thompson
2026-11-03 14:45     ` Roman Vivchar
2026-11-03 14:58       ` Daniel Thompson

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=auoVaaZjcnRTj1S9@aspen.lan \
    --to=danielt@kernel.org \
    --cc=conor+dt@kernel.org \
    --cc=deller@gmx.de \
    --cc=devicetree@vger.kernel.org \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=jingoohan1@gmail.com \
    --cc=krzk+dt@kernel.org \
    --cc=lee@kernel.org \
    --cc=linux-fbdev@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-leds@vger.kernel.org \
    --cc=pavel@kernel.org \
    --cc=robh@kernel.org \
    --cc=rva333@protonmail.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 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.