| 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
| ||
|
Message-ID: <d1d83ca2-d856-4e30-b53f-6b601a287768@gocontroll.com>
Date: Tue, 16 Dec 2025 09:19:40 +0100
From: Maud Spierings <maudspierings@...ontroll.com>
To: Rob Herring <robh@...nel.org>
Cc: Frank Li <Frank.li@....com>, Lee Jones <lee@...nel.org>,
Daniel Thompson <danielt@...nel.org>, Jingoo Han <jingoohan1@...il.com>,
Pavel Machek <pavel@...nel.org>, Krzysztof Kozlowski <krzk+dt@...nel.org>,
Conor Dooley <conor+dt@...nel.org>, Helge Deller <deller@....de>,
Shawn Guo <shawnguo@...nel.org>, Sascha Hauer <s.hauer@...gutronix.de>,
Pengutronix Kernel Team <kernel@...gutronix.de>,
Fabio Estevam <festevam@...il.com>, Liam Girdwood <lgirdwood@...il.com>,
Mark Brown <broonie@...nel.org>, dri-devel@...ts.freedesktop.org,
linux-leds@...r.kernel.org, devicetree@...r.kernel.org,
linux-kernel@...r.kernel.org, linux-fbdev@...r.kernel.org,
imx@...ts.linux.dev, linux-arm-kernel@...ts.infradead.org
Subject: Re: [PATCH v6 1/4] dt-bindings: backlight: Add max25014 support
On 12/9/25 20:07, Rob Herring wrote:
> On Mon, Dec 08, 2025 at 02:56:50PM +0100, Maud Spierings wrote:
>> On 12/2/25 15:53, Frank Li wrote:
>>> On Tue, Dec 02, 2025 at 08:46:21AM +0100, Maud Spierings wrote:
>>>> On 12/1/25 17:52, Frank Li wrote:
>>>>> On Mon, Dec 01, 2025 at 12:53:20PM +0100, Maud Spierings via B4 Relay wrote:
>>>>>> From: Maud Spierings <maudspierings@...ontroll.com>
>>>>>>
>>>>>> The Maxim MAX25014 is a 4-channel automotive grade backlight driver IC
>>>>>> with integrated boost controller.
>>>>>>
>>>>>> Signed-off-by: Maud Spierings <maudspierings@...ontroll.com>
>>>>>>
>>>>>> ---
>>>>>>
>>>>>> In the current implementation the control registers for channel 1,
>>>>>> control all channels. So only one led subnode with led-sources is
>>>>>> supported right now. If at some point the driver functionality is
>>>>>> expanded the bindings can be easily extended with it.
>>>>>> ---
>>>>>> .../bindings/leds/backlight/maxim,max25014.yaml | 107 +++++++++++++++++++++
>>>>>> MAINTAINERS | 5 +
>>>>>> 2 files changed, 112 insertions(+)
>>>>>>
>>>>>> diff --git a/Documentation/devicetree/bindings/leds/backlight/maxim,max25014.yaml b/Documentation/devicetree/bindings/leds/backlight/maxim,max25014.yaml
>>>>>> new file mode 100644
>>>>>> index 000000000000..e83723224b07
>>>>>> --- /dev/null
>>>>>> +++ b/Documentation/devicetree/bindings/leds/backlight/maxim,max25014.yaml
>>>>>> @@ -0,0 +1,107 @@
>>>>>> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
>>>>>> +%YAML 1.2
>>>>>> +---
>>>>>> +$id: http://devicetree.org/schemas/leds/backlight/maxim,max25014.yaml#
>>>>>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
>>>>>> +
>>>>>> +title: Maxim max25014 backlight controller
>>>>>> +
>>>>>> +maintainers:
>>>>>> + - Maud Spierings <maudspierings@...ontroll.com>
>>>>>> +
>>>>>> +properties:
>>>>>> + compatible:
>>>>>> + enum:
>>>>>> + - maxim,max25014
>>>>>> +
>>>>>> + reg:
>>>>>> + maxItems: 1
>>>>>> +
>>>>>> + "#address-cells":
>>>>>> + const: 1
>>>>>> +
>>>>>> + "#size-cells":
>>>>>> + const: 0
>>>>>> +
>>>>>> + enable-gpios:
>>>>>> + maxItems: 1
>>>>>> +
>>>>>> + interrupts:
>>>>>> + maxItems: 1
>>>>>> +
>>>>>> + power-supply:
>>>>>> + description: Regulator which controls the boost converter input rail.
>>>>>> +
>>>>>> + pwms:
>>>>>> + maxItems: 1
>>>>>> +
>>>>>> + maxim,iset:
>>>>>> + $ref: /schemas/types.yaml#/definitions/uint32
>>>>>> + maximum: 15
>>>>>> + default: 11
>>>>>> + description:
>>>>>> + Value of the ISET field in the ISET register. This controls the current
>>>>>> + scale of the outputs, a higher number means more current.
>>>>>> +
>>>>>> + led@0:
>>>>>
>>>>> define whole binding, allow 0-3. binding is not related with driver's
>>>>> implement.
>>>>>
>>>>> it'd better put unders leds.
>>>>>
>>>>
>>>> so like:
>>>>
>>>> backlight: backlight@6f {
>>>> compatible = "maxim,max25014";
>>>> reg = <0x6f>;
>>>> enable-gpios = <&gpio1 4 GPIO_ACTIVE_HIGH>;
>>>> pinctrl-names = "default";
>>>> pinctrl-0 = <&pinctrl_backlight>;
>>>> maxim,iset = <7>;
>>>>
>>>> leds {
>>>> #address-cells = <1>;
>>>> #size-cells = <0>;
>>>>
>>>> led@0 {
>>>> reg = <0>;
>>>> led-sources = <0 1 2>;
>>>> default-brightness = <50>;
>>>> };
>>>>
>>>> optional led@.....
>>>> };
>>>> };
>>>>
>>>> right?
>>>
>>> yes.
>>>
>>
>> I am feeling a bit weird about these led sub nodes, because it is not
>> programmed as a led driver, it is programmed as a backlight. I am trying to
>> figure out how this would be used later when the led strings are
>> individually controllable.
>>
>> it isn't possible to link the seperate strings to different displays because
>> it is only one backlight device, so I don't seen any reason why it would
>> ever be used in another way than what it is now, were all strings are
>> programmed by one register.
>>
>> The only way I can make sense of it is if instead I program this device as a
>> led driver and then use the led_bl driver as the actual backlight.
>>
>> Thats a pretty big step in a different direction, but then the led subnodes
>> at least can be properly used I feel.
>
> If you don't have any use for anything other than driving a single
> backlight, then I'd just drop the led nodes completely.
Theoretically with how the registers are laid out, it should be able to
control 4 led strings individually. But as I said when I configure led
string 1 it will also affect all the others seemingly. I am not sure if
with some other configuration you can indeed do individual control.
Before I start converting stuff back to how it was several versions ago.
Frank, do you agree with removing the led nodes in this case? I don't
want to get stuck between two different paths.
Kind regards,
Maud
Powered by blists - more mailing lists