On 27/01/2026 13:46, tessolveupstream@gmail.com wrote:
On 23-01-2026 16:41, tessolveupstream@gmail.com wrote:
quoted
On 20-01-2026 20:01, Krzysztof Kozlowski wrote:
quoted
On 20/01/2026 13:50, Sudarshan Shetty wrote:
quoted
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 (local)
quoted
quoted
Signed-off-by: Sudarshan Shetty <redacted>
---
.../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
quoted
+ 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