linux-kernel - Re: PWM backlight initial state assumptions, or how pwm_bl killed my (nyan) cat^W backlight support

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] [thread-next>] [day] [month] [year] [list]

Date:   Thu, 6 Jul 2017 13:57:43 +0100
From:   Daniel Thompson <daniel.thompson@...aro.org>
To:     Paul Kocialkowski <contact@...lk.fr>,
        Philipp Zabel <p.zabel@...gutronix.de>
Cc:     linux-pwm@...r.kernel.org, linux-kernel@...r.kernel.org,
        Thierry Reding <thierry.reding@...il.com>,
        Lee Jones <lee.jones@...aro.org>,
        Jingoo Han <jingoohan1@...il.com>
Subject: Re: PWM backlight initial state assumptions, or how pwm_bl killed my
 (nyan) cat^W backlight support

On 06/07/17 13:41, Paul Kocialkowski wrote:
>>> Some panels have a documented powerup sequence, which usually ends with
>>> the backlight being enabled to avoid showing garbage before the panel is
>>> initialized completely.
>>> The reason for 3698d7e7d221 was a device with the display disabled out
>>> of the bootloader, where the backlight is controlled by the simple-panel
>>> driver. Enabling the backlight from the backlight driver before the
>>> panel driver requests the backlight to be enabled (before the panel is
>>> powered) would result in a white flash during boot.
>>>
>>> I tried to be careful to only let the backlight driver set the initial
>>> state to disabled if a few conditions are met: the GPIO is already
>>> configured as output and disabled, and the backlight device tree node
>>> has a phandle pointing to it, so we can expect there to be some
>>> controlling instance that will enable it when appropriate.
>>>
>>> I wonder why in your case there is a phandle link to the backlight node
>>> but nothing actually enables the backlight during boot. I would expect
>>> that to be handled by the panel driver.
>>
>> I had completely missed the fact that the panel driver is supposed to request
>> backlight enable! With that in mind, this policy no longer concerns "the whole
>> lifetime of the driver" but only the timeframe between backlight probe and
>> panel
>> probe. Thanks for clarifying this. I suppose I agree with this policy now.
>>
>> So remains the question: why does the panel not enable backlight on my device?
>>
>> I will investigate this later today. Hopefully, the probe defer logic should
>> prevent a case where the panel is probed (to the end) before the backlight
>> driver.
> 
> This is actually due to the tegra drm driver not probing. It is happening on my
> setup (with a somewhat custom, out-of-tree config) on both jetson-tk1 and
> nyan_big, but also on kernelci, running both tegra_defconfig and
> multi_v7_defconfig.
> 
> Since this is no longer a concern related to the pwm backlight driver, I will
> start a new thread with the relevant addresses in CC.

Thanks for the update. Much appreciated!

BTW, I got the impression from your first mail that you are chasing a 
regression between v4.11 and v4.12. If that's the case you should know 
that the backlight changes we have been discussing landed in v4.11 (so 
if you do have a regression between these two releases then mentioning 
backlight in the other thread may just be confusing).


Daniel.