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: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <304ef935-e82b-4556-be3c-6ec4f57cf68c@gmail.com>
Date: Thu, 29 Jan 2026 11:11:34 +0530
From: tessolveupstream@...il.com
To: Daniel Thompson <daniel@...cstar.com>,
 Krzysztof Kozlowski <krzk@...nel.org>
Cc: lee@...nel.org, danielt@...nel.org, jingoohan1@...il.com, 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 28-01-2026 16:50, Daniel Thompson wrote:
> On Wed, Jan 28, 2026 at 11:11:33AM +0100, Krzysztof Kozlowski wrote:
>> 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.
> 
> Sudarshan: I believe at one point the intent was to model this hardware
> as a pwm-backlight (using enables GPIOs to drive the enable pin)
> attached to a pwm-gpio (to drive the PWM pin). Did this approach work?
> 

Yes, the original plan was to model this using pwm‑gpio, and that 
setup worked. But on the SOC there’s no actual PWM controller available 
for this path— the LED_PWM line is just tied to a GPIO that’s driven 
high (effectively a fixed 100% duty cycle). Because of that, describing 
it as a PWM in DT was flagged as incorrect.

As pointed out during the SoC DTS review, the correct path forward is 
to extend gpio‑backlight to handle multiple GPIOs, rather than 
representing them as multiple separate backlight devices.

> 
> Daniel.


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ