From: Sakari Ailus <sakari.ailus@linux.intel.com>
To: Lee Jones <lee@kernel.org>
Cc: Rillian Grant <rillian.grant@gmail.com>,
Andy Shevchenko <andriy.shevchenko@linux.intel.com>,
Daniel Scally <djrscally@gmail.com>,
Heikki Krogerus <heikki.krogerus@linux.intel.com>,
Bartosz Golaszewski <brgl@kernel.org>,
Pavel Machek <pavel@kernel.org>, Rob Herring <robh@kernel.org>,
Krzysztof Kozlowski <krzk+dt@kernel.org>,
Conor Dooley <conor+dt@kernel.org>,
Ruslan Koreev <koreev.r@gmail.com>,
linux-leds@vger.kernel.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH v3 3/4] leds: flash: lm3643: Describe the LED of ACPI boards without LED nodes
Date: Tue, 20 Oct 2026 14:19:46 +0300 [thread overview]
Message-ID: <atdOUv937j63NKAL@kekkonen.localdomain> (raw)
In-Reply-To: <179198404917.839288.1364319566324835013@kernel.org>
Hi Lee, others,
On Tue, Oct 20, 2026 at 11:45:06AM +0100, Lee Jones wrote:
> > @@ -691,6 +692,92 @@ static int lm3643_register_led(struct device *dev, struct lm3643 *chip,
> > return lm3643_register_v4l2(dev, led, fwnode);
> > }
> >
> > +/*
> > + * Lenovo ThinkPads enumerate the chip through ACPI (HID TXNW3643) without a
> > + * _DSD, so the LED is not described by firmware. On the boards below it drives
> > + * the Windows Hello IR flood illuminator, with both current sources feeding a
> > + * single LED. Describe that with a software node, with torch and flash limits
> > + * (100 mA and 300 mA per output) well below the chip's maximums.
> > + */
> > +static const u32 lm3643_ir_flood_sources[] = { 0, 1 };
> > +
> > +static const struct property_entry lm3643_ir_flood_props[] = {
> > + PROPERTY_ENTRY_U32("reg", 0),
> > + PROPERTY_ENTRY_U32_ARRAY("led-sources", lm3643_ir_flood_sources),
> > + PROPERTY_ENTRY_STRING("function", LED_FUNCTION_FLASH),
> > + PROPERTY_ENTRY_U32("color", LED_COLOR_ID_IR),
> > + PROPERTY_ENTRY_U32("led-max-microamp", 200000),
> > + PROPERTY_ENTRY_U32("flash-max-microamp", 600000),
> > + PROPERTY_ENTRY_U32("flash-max-timeout-us", 100000),
> > + { }
> > +};
> > +
> > +static const struct software_node lm3643_ir_flood_root = {
> > + .name = "lm3643",
> > +};
> > +
> > +static const struct software_node lm3643_ir_flood_led = {
> > + .name = "led-0",
> > + .parent = &lm3643_ir_flood_root,
> > + .properties = lm3643_ir_flood_props,
> > +};
> > +
> > +static const struct software_node *lm3643_ir_flood_nodes[] = {
> > + &lm3643_ir_flood_root,
> > + &lm3643_ir_flood_led,
> > + NULL
> > +};
> > +
> > +static const struct dmi_system_id lm3643_dmi_leds[] = {
> > + {
> > + /* Lenovo ThinkPad X1 Carbon Gen 14 */
> > + .matches = {
> > + DMI_EXACT_MATCH(DMI_SYS_VENDOR, "LENOVO"),
> > + DMI_EXACT_MATCH(DMI_PRODUCT_VERSION, "ThinkPad X1 Carbon Gen 14"),
> > + },
> > + .driver_data = (void *)lm3643_ir_flood_nodes,
>
> Andy, et al.,
>
> I don't usually allow data from other registration mechanisms to be
> passed through another (MFD data via OF for instance).
>
> Is this okay?
In this case the ipu-bridge needs to provide the information to the lm3643
driver via software nodes, as it already does for a number of other
devices. There's no point in putting the information to the LED driver.
Presumably the ACPI device node already exists so this should be
straightforward. What's also missing from the sensor then is the flash-leds
property, the lens-focus handling serves as an example.
--
Regards,
Sakari Ailus
next prev parent reply other threads:[~2026-10-20 11:19 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-11 19:09 [PATCH v3 0/4] leds: flash: LM3643 dual LED flash driver Rillian Grant
2026-10-11 19:09 ` [PATCH v3 1/4] dt-bindings: leds: Document TI " Rillian Grant
2026-10-12 9:51 ` Krzysztof Kozlowski
2026-10-11 19:09 ` [PATCH v3 2/4] leds: flash: Add support for the " Rillian Grant
2026-10-11 19:09 ` [PATCH v3 3/4] leds: flash: lm3643: Describe the LED of ACPI boards without LED nodes Rillian Grant
2026-10-20 10:45 ` Lee Jones
2026-10-20 11:19 ` Sakari Ailus [this message]
2026-10-11 19:09 ` [PATCH v3 4/4] leds: flash: lm3643: Describe the LED on the Lenovo ThinkPad X9-15 Gen 1 Rillian Grant
2026-10-20 10:54 ` Lee Jones
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=atdOUv937j63NKAL@kekkonen.localdomain \
--to=sakari.ailus@linux.intel.com \
--cc=andriy.shevchenko@linux.intel.com \
--cc=brgl@kernel.org \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=djrscally@gmail.com \
--cc=heikki.krogerus@linux.intel.com \
--cc=koreev.r@gmail.com \
--cc=krzk+dt@kernel.org \
--cc=lee@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-leds@vger.kernel.org \
--cc=pavel@kernel.org \
--cc=rillian.grant@gmail.com \
--cc=robh@kernel.org \
/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
all inboxes | Powered by JetHome®