linux-kernel - Re: [PATCH v6 1/4] dt-bindings: backlight: Add max25014 support

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <e428c3a9-49e2-4af5-b597-2cdfef7028f5@gocontroll.com>
Date: Mon, 8 Dec 2025 14:56:50 +0100
From: Maud Spierings <maudspierings@...ontroll.com>
To: Frank Li <Frank.li@....com>
Cc: Lee Jones <lee@...nel.org>, Daniel Thompson <danielt@...nel.org>,
 Jingoo Han <jingoohan1@...il.com>, Pavel Machek <pavel@...nel.org>,
 Rob Herring <robh@...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/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.

Kind regards,
Maud