linux-kernel - Re: How to handle quirky behavior with boards.

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:   Fri, 3 Mar 2017 16:31:43 +0100
From:   Olliver Schinagl <o.schinagl@...imaker.com>
To:     Olliver Schinagl <o.schinagl@...imaker.com>,
        dev <dev@...ux-sunxi.org>
Cc:     "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        oliver+list@...inagl.nl, Mark Brown <broonie@...nel.org>,
        Liam Girdwood <lgirdwood@...il.com>,
        Carlo Caione <carlo@...one.org>,
        Maxime Ripard <maxime.ripard@...e-electrons.com>
Subject: Re: How to handle quirky behavior with boards.

Hey all,

Sorry for top-posting, but I did not want to break the thread, while the 
initial mail does provide background information.

So I've implemented a software-based soft-start in the regulator_enable 
function of the axp209. This works as expected. Whether it is the right 
solution I'll happily debate with the patch-set I'm about to send.

The question that remains however, is how is voltage ramping supposed to 
work?

Right now, the core checks and setups various constraints. Two which are 
somewhat in conflicting order are:

regulator-always-on

and

ramp-delay.

If, for reasons outside of our control the regulator was not on during 
boot (miss-configured u-boot) but we want it to be always-on from the 
kernel side of things, we run into a problem, because the kernel turns 
the regulator on first (because of regulator-always-on) and only then 
sets its constraints.

Now we could in our specific case, tell the driver to check for the 
ramp-delay constraint, and then run it during init/probe, but that feels 
a little bit like a hack.

So my question is, what is there against moving some of the constrants 
before the always-on, so that the enable can atleast function properly 
according to its parameters?

Olliver

On 01-03-17 14:58, Olliver Schinagl wrote:
> Hey all,
>
> We found a bug in the design of a board that we use. This board (Olimex
> OLinuXino Lime2) features a PMIC (AXP209) and has an LDO, LDO3, that
> needs special treatment.
>
> The bug is, that there is too much capacitance on the output of LDO3,
> which causes the PMIC to shutdown when enabeling LDO3.
>
> The AXP does have voltage ramp control for LDO3, but this is only
> effective After LDO3 has been enabled.
>
> To be able to turn on LDO3, we have to first set its voltage to the
> lowest setting (0.7 V), wait 1 ms, then turn it on. After that the
> voltage can be changed normally.
>
> I'm already working on the patches to add the voltage ramp control but
> as described above, this will not fix the problem here.
>
> My guess, and hence the question, is that we will need to add support
> for this quirk in the AXP209 LDO3 enable case. There are no quirk flags
> that I could find yet, so how is this preferabbly handled? A board level
> flag in the dts? AXP-level flag? Or is the soft-start flag sort of
> inteded for this? e.g. set soft-start for ldo3 in the dts, check this
> flag in the enable function and do the earlier described start-up?
>
> Thanks,
>
> Olliver