linux-kernel - Re: [PATCH v3 2/4] dt-bindings: leds: commonize leds property

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: <dMbLo1ph9fkRREvsauWvJiPeAWXSJwCHx1dgUC_1xcJvDPjOzydsGiEUipaM_KZqeiwgacNxZbAvSLndg1jo2LnFaKcnFJK72S-NFtjuHOA=@vinarskis.com>
Date: Mon, 08 Sep 2025 10:47:27 +0000
From: Aleksandrs Vinarskis <alex@...arskis.com>
To: Konrad Dybcio <konrad.dybcio@....qualcomm.com>
Cc: Hans de Goede <hansg@...nel.org>, Lee Jones <lee@...nel.org>, Pavel Machek <pavel@...nel.org>, Rob Herring <robh@...nel.org>, Krzysztof Kozlowski <krzk+dt@...nel.org>, Conor Dooley <conor+dt@...nel.org>, Bryan O'Donoghue <bryan.odonoghue@...aro.org>, Daniel Thompson <danielt@...nel.org>, Jingoo Han <jingoohan1@...il.com>, Mauro Carvalho Chehab <mchehab@...nel.org>, Jean-Jacques Hiblot <jjhiblot@...phandler.com>, Jacopo Mondi <jacopo@...ndi.org>, Sakari Ailus <sakari.ailus@...ux.intel.com>, Bjorn Andersson <andersson@...nel.org>, Konrad Dybcio <konradybcio@...nel.org>, linux-leds@...r.kernel.org, devicetree@...r.kernel.org, linux-kernel@...r.kernel.org, Daniel Thompson <daniel.thompson@...aro.org>, dri-devel@...ts.freedesktop.org, linux-media@...r.kernel.org, linux-arm-msm@...r.kernel.org
Subject: Re: [PATCH v3 2/4] dt-bindings: leds: commonize leds property






On Monday, September 8th, 2025 at 09:36, Konrad Dybcio <konrad.dybcio@....qualcomm.com> wrote:

> 
> 
> On 9/8/25 9:33 AM, Hans de Goede wrote:
> 
> > Hi,
> > 
> > On 8-Sep-25 09:20, Konrad Dybcio wrote:
> > 
> > > On 9/8/25 1:18 AM, Aleksandrs Vinarskis wrote:
> > > 
> > > > A number of existing schemas use 'leds' property to provide
> > > > phandle-array of LED(s) to the consumer. Additionally, with the
> > > > upcoming privacy-led support in device-tree, v4l2 subnode could be a
> > > > LED consumer, meaning that all camera sensors should support 'leds'
> > > > and 'led-names' property via common 'video-interface-devices.yaml'.
> > > > 
> > > > To avoid dublication, commonize 'leds' property from existing schemas
> > > > to newly introduced 'led-consumer.yaml'.
> > > > 
> > > > Signed-off-by: Aleksandrs Vinarskis alex@...arskis.com
> > > > ---
> > > 
> > > [...]
> > > 
> > > > + leds:
> > > > + minItems: 1
> > > > + maxItems: 1
> > > 
> > > My brain compiler suggests this will throw a warning (minItems should
> > > be redundant in this case)

No complaints when running `dt_bindings_check` on this nor the camera sensor
that uses this binding. I thought it would be better to keep it even though
right now only one LED is supported, so that when `led-names` are extended
with new functions, one can just bump maxItems and not accidentally forget
to introduce minItems. No strong opinion though, perhaps Rob can decide
since he is the one that suggested to add minItems,maxItems that I didn't
think of?

> > > 
> > > > +
> > > > + led-names:
> > > > + enum:
> > > > + - privacy-led
> > > 
> > > Nit: "privacy" makes more sense without the suffix, as we inherently
> > > know this is supposed to be an LED
> > 
> > Note "privacy-led" as name is already used on the x86/ACPI side and
> > the code consuming this will be shared.
> > 
> > With that said if there is a strong preference for going with just
> > "privacy" the x86 side can be adjusted since the provider-info is
> > generated through a LED lookup table on the x86/ACPI side. So we can
> > just modify both the lookup table generation as well as the already
> > existing led_get(dev, "privacy-led") call to use just "privacy"
> > without problems.
> 
> 
> In that case, it may be cleaner to just go with what we have today
> (unless the dt maintainers have stronger opinions)

Sounds good, thanks both for the feedback.

Alex

> 
> Konrad