linux-kernel - Re: [PATCH v2 2/2] leds: add Qualcomm PM8941 WLED driver

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: <54E3FCD3.4000304@codeaurora.org>
Date:	Tue, 17 Feb 2015 18:45:39 -0800
From:	Stephen Boyd <sboyd@...eaurora.org>
To:	Bjorn Andersson <bjorn@...o.se>
CC:	Bjorn Andersson <bjorn.andersson@...ymobile.com>,
	Rob Herring <robh+dt@...nel.org>,
	Pawel Moll <pawel.moll@....com>,
	Mark Rutland <mark.rutland@....com>,
	Ian Campbell <ijc+devicetree@...lion.org.uk>,
	Kumar Gala <galak@...eaurora.org>,
	Bryan Wu <cooloney@...il.com>,
	Richard Purdie <rpurdie@...ys.net>,
	Grant Likely <grant.likely@...aro.org>,
	Courtney Cavin <courtney.cavin@...ymobile.com>,
	"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Linux LED Subsystem <linux-leds@...r.kernel.org>,
	linux-arm-msm <linux-arm-msm@...r.kernel.org>
Subject: Re: [PATCH v2 2/2] leds: add Qualcomm PM8941 WLED driver

On 02/17/15 15:02, Bjorn Andersson wrote:
> On Thu, Feb 12, 2015 at 8:26 PM, Stephen Boyd <sboyd@...eaurora.org> wrote:
>> On 01/23/15 16:54, Bjorn Andersson wrote:
>>> +
>>> +static int pm8941_wled_set(struct led_classdev *cdev,
>>> +                        enum led_brightness value)
>>> +{
>>> +     struct pm8941_wled *wled;
>>> +     u8 ctrl = 0;
>>> +     u16 val;
>>> +     int rc;
>>> +     int i;
>>> +
>>> +     wled = container_of(cdev, struct pm8941_wled, cdev);
>>> +
>>> +     if (value != 0)
>>> +             ctrl = PM8941_WLED_REG_MOD_EN_BIT;
>>> +
>>> +     val = value * PM8941_WLED_REG_VAL_MAX / LED_FULL;
>>> +
>>> +     rc = regmap_update_bits(wled->regmap,
>>> +                     wled->addr + PM8941_WLED_REG_MOD_EN,
>>> +                     PM8941_WLED_REG_MOD_EN_MASK, ctrl);
>>> +     if (rc)
>>> +             return rc;
>>> +
>>> +     for (i = 0; i < wled->cfg.num_strings; ++i) {
>>> +             u8 v[2] = { val & 0xff, (val >> 8) & 0xf };
>>> +
>>> +             rc = regmap_bulk_write(wled->regmap,
>>> +                             wled->addr + PM8941_WLED_REG_VAL_BASE + 2 * i,
>>> +                             v, 2);
>>> +             if (rc)
>>> +                     return rc;
>>> +     }
>>> +
>>> +     rc = regmap_update_bits(wled->regmap,
>>> +                     wled->addr + PM8941_WLED_REG_SYNC,
>>> +                     PM8941_WLED_REG_SYNC_MASK, PM8941_WLED_REG_SYNC_ALL);
>>> +     if (rc)
>>> +             return rc;
>>> +
>>> +     rc = regmap_update_bits(wled->regmap,
>>> +                     wled->addr + PM8941_WLED_REG_SYNC,
>>> +                     PM8941_WLED_REG_SYNC_MASK, PM8941_WLED_REG_SYNC_CLEAR);
>>> +     return rc;
>>> +}
>> This doesn't seem to do anything for the OVP spike mentioned in this
>> patch[1]. Do you see that problem on your device? I imagine the PMIC is
>> the same.
>>
>> [1]
>> https://www.codeaurora.org/cgit/quic/la/kernel/msm/commit/?id=fef9e15072562f0f28dc7066dcdd69388df81ed3
>>
> That's odd, I can't find that fix in any officially supported releases
> for 8974 - which Courtney used as reference for this driver.
>
> Just to make sure I understand the solution; when disabling the sinks
> the over-voltage-protection sometimes triggers, so we should detect
> that and reset the ovp configuration?
>
> I presume the side effect would be that the sinks would not give any
> output until this is done?
>

It seems that commit is not very good at describing the problem. From
what I can tell, the inductor current may spike when the WLED is turned
off and the switch is stuck on (the circuit is a boost convertor). To
make sure this doesn't happen, we force an OVP so that the switch is
known to be open (i.e. off) and thus can't cause the current spike when
we disable.

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/