On 27/01/2026 13:46, [email protected] wrote: > > > On 23-01-2026 16:41, [email protected] wrote: >> >> >> On 20-01-2026 20:01, Krzysztof Kozlowski wrote: >>> On 20/01/2026 13:50, Sudarshan Shetty wrote: >>>> Update the gpio-backlight binding to support configurations that require >>>> more than one GPIO for enabling/disabling the backlight. >>> >>> >>> Why? Which devices need it? How a backlight would have three enable >>> GPIOs? I really do not believe, so you need to write proper hardware >>> justification. >>> >> >> To clarify our hardware setup: >> the panel requires one GPIO for the backlight enable signal, and it >> also has a PWM input. Since the QCS615 does not provide a PWM controller >> for this use case, the PWM input is connected to a GPIO that is driven >> high to provide a constant 100% duty cycle, as explained in the link >> below. >> https://lore.kernel.org/all/[email protected]/T/#m93ca4e5c7bf055715ed13316d91f0cd544244cf5 >> >>>> >>>> Signed-off-by: Sudarshan Shetty <[email protected]> >>>> --- >>>> .../leds/backlight/gpio-backlight.yaml | 24 +++++++++++++++++-- >>>> 1 file changed, 22 insertions(+), 2 deletions(-) >>>> >>>> diff --git >>>> a/Documentation/devicetree/bindings/leds/backlight/gpio-backlight.yaml >>>> b/Documentation/devicetree/bindings/leds/backlight/gpio-backlight.yaml >>>> index 584030b6b0b9..4e4a856cbcd7 100644 >>>> --- a/Documentation/devicetree/bindings/leds/backlight/gpio-backlight.yaml >>>> +++ b/Documentation/devicetree/bindings/leds/backlight/gpio-backlight.yaml >>>> @@ -16,8 +16,18 @@ properties: >>>> const: gpio-backlight >>>> >>>> gpios: >>>> - description: The gpio that is used for enabling/disabling the >>>> backlight. >>>> - maxItems: 1 >>>> + description: | >>>> + The gpio that is used for enabling/disabling the backlight. >>>> + Multiple GPIOs can be specified for panels that require several >>>> + enable signals. All GPIOs are controlled together. >>>> + type: array >>> >>> There is no such syntax in the bindings, from where did you get it? Type >>> is already defined. >>> >>> items: >>> minItems: 1 >>> maxItems: 3 >>> >>> >>>> + minItems: 1 >>>> + items: >>>> + type: array >>>> + minItems: 3 >>>> + maxItems: 3 >>>> + items: >>>> + type: integer >>> >>> All this is some odd stuff - just to be clear, don't send us LLM output. >>> I don't want to waste my time to review microslop. >>> >>> Was it done with help of Microslop? >>> >> >> I understand now that the schema changes I proposed were not correct, >> and I will address this in the next patch series. My intention was to >> check whether the gpio-backlight binding could support more than one >> enable-type GPIO. >> Could you please advise what would be an appropriate maximum number of >> GPIOs for gpio-backlight in such a scenario? For example, would allowing >> 2 GPIOs be acceptable, or should this case be handled in a different way? >> > > In line with Daniel’s suggestion, I am planning to adopt a fixed upper > limit for the number of backlight GPIOs. The current hardware only > requires two GPIOs, so the maxItems can be set to 2. > > If future platforms or customers require support for a higher number > of GPIOs, this limit can be increased and the driver can be > updated accordingly. > > Kindly advise if this solution aligns with your expectations, or if > you prefer an alternative maximum value.
You have entire commit msg to explain the hardware and explain WHY you are doing this. In a concise and readable way. I will not be going through 2 different email threads with 20 messages to figure that out. Best regards, Krzysztof
