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]
Message-ID: <0d41f3eb83bbae9eaab0723a84bfcb1b@codeaurora.org>
Date:   Tue, 22 Oct 2019 12:50:16 +0530
From:   kgunda@...eaurora.org
To:     Daniel Thompson <daniel.thompson@...aro.org>
Cc:     bjorn.andersson@...aro.org, jingoohan1@...il.com,
        lee.jones@...aro.org, b.zolnierkie@...sung.com,
        dri-devel@...ts.freedesktop.org, jacek.anaszewski@...il.com,
        pavel@....cz, robh+dt@...nel.org, mark.rutland@....com,
        linux-leds@...r.kernel.org, devicetree@...r.kernel.org,
        linux-kernel@...r.kernel.org, Andy Gross <agross@...nel.org>,
        linux-arm-msm@...r.kernel.org, linux-fbdev@...r.kernel.org
Subject: Re: [PATCH V8 6/6] backlight: qcom-wled: Add auto string detection
 logic

On 2019-10-21 16:01, Daniel Thompson wrote:
> On Fri, Oct 18, 2019 at 06:03:29PM +0530, Kiran Gunda wrote:
>> The auto string detection algorithm checks if the current WLED
>> sink configuration is valid. It tries enabling every sink and
>> checks if the OVP fault is observed. Based on this information
>> it detects and enables the valid sink configuration.
>> Auto calibration will be triggered when the OVP fault interrupts
>> are seen frequently thereby it tries to fix the sink configuration.
>> 
>> The auto-detection also kicks in when the connected LED string
>> of the display-backlight malfunctions (because of damage) and
>> requires the damaged string to be turned off to prevent the
>> complete panel and/or board from being damaged.
>> 
>> Signed-off-by: Kiran Gunda <kgunda@...eaurora.org>
>> ---
>>  drivers/video/backlight/qcom-wled.c | 398 
>> +++++++++++++++++++++++++++++++++++-
>>  1 file changed, 392 insertions(+), 6 deletions(-)
>> 
>> diff --git a/drivers/video/backlight/qcom-wled.c 
>> b/drivers/video/backlight/qcom-wled.c
>> index 658b1e0..b2e6754 100644
>> --- a/drivers/video/backlight/qcom-wled.c
>> +++ b/drivers/video/backlight/qcom-wled.c
>> @@ -193,7 +216,23 @@ static int wled_module_enable(struct wled *wled, 
>> int val)
>>  				WLED3_CTRL_REG_MOD_EN,
>>  				WLED3_CTRL_REG_MOD_EN_MASK,
>>  				val << WLED3_CTRL_REG_MOD_EN_SHIFT);
>> -	return rc;
>> +	if (rc < 0)
>> +		return rc;
>> +
>> +	if (wled->ovp_irq > 0) {
>> +		if (val) {
>> +			/*
>> +			 * Wait for at least 10ms before enabling OVP interrupt
>> +			 * after module enable so that soft start is completed.
>> +			 */
> 
> Comments should not say what is does (we can read that). It should be
> saying what is weird about the hardware the results in us enabling the
> interrupt in an unusual way.
> 
> More like:
> 
> "The hardware generates a storm of spurious OVP interrupts during soft
> start operations so defer enabling the IRQ for 10ms to ensure that
> the soft start is complete."
> 
> Note that I am only guessing that is an spurious interrupt storm that
> caused you to defer the interrupt enable... I don't want to have to
> guess which is why I am asking for a good quality comment!
> 
> 
> Daniel.
Yes. Your guess is correct. The hardware document explains the same.
The WLED boost voltage can hit OVP limit in normal operating conditions 
such as
during the soft start timing.
Hence, waiting for the soft start to complete before enabling the OVP 
interrupt
to avoid the spurious interrupts.

I will update the comment as you suggested in the next series.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ