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

[Maud Spierings]

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 at gocontroll.com>
>>>>>>
>>>>>> The Maxim MAX25014 is a 4-channel automotive grade backlight driver IC
>>>>>> with integrated boost controller.
>>>>>>
>>>>>> Signed-off-by: Maud Spierings <maudspierings at gocontroll.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 at gocontroll.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 at 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 at 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 at 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