[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <500b603d-5abc-4c45-8d56-bbc88fc85b83@kernel.org>
Date: Wed, 28 Jan 2026 11:11:33 +0100
From: Krzysztof Kozlowski <krzk@...nel.org>
To: tessolveupstream@...il.com, lee@...nel.org, danielt@...nel.org,
jingoohan1@...il.com
Cc: deller@....de, pavel@...nel.org, robh@...nel.org, krzk+dt@...nel.org,
conor+dt@...nel.org, dri-devel@...ts.freedesktop.org,
linux-fbdev@...r.kernel.org, linux-leds@...r.kernel.org,
devicetree@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2 1/2] dt-bindings: backlight: gpio-backlight: allow
multiple GPIOs
On 23/01/2026 12:11, tessolveupstream@...il.com 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/20251028061636.724667-1-tessolveupstream@gmail.com/T/#m93ca4e5c7bf055715ed13316d91f0cd544244cf5
That's not an enable gpio, but PWM.
You write bindings for this device, not for something else - like your
board.
>
>>>
>>> Signed-off-by: Sudarshan Shetty <tessolveupstream@...il.com>
>>> ---
>>> .../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,
How such code could be even created... Just in case, do you understand
that Microslop and LLM is waste of our time?
> 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?
We have plenty of examples for this, but anyway you won't need it
because this is not an enable GPIO.
Best regards,
Krzysztof
Powered by blists - more mailing lists