linux-kernel - Re: [PATCH] arm: dts: fix rk3066a based boards vdd

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: <CAD=FV=Ufmvg1P8suOPQ53kpOD1pei4N2dOpKUCxZk001XKj_OA@mail.gmail.com>
Date:   Mon, 19 Sep 2016 10:22:43 -0700
From:   Doug Anderson <dianders@...omium.org>
To:     Boris Brezillon <boris.brezillon@...e-electrons.com>
Cc:     Heiko Stuebner <heiko@...ech.de>,
        Andy Yan <andy.yan@...k-chips.com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "open list:ARM/Rockchip SoC..." <linux-rockchip@...ts.infradead.org>,
        "linux-arm-kernel@...ts.infradead.org" 
        <linux-arm-kernel@...ts.infradead.org>
Subject: Re: [PATCH] arm: dts: fix rk3066a based boards vdd_log voltage initialization

Hi,

On Mon, Sep 19, 2016 at 10:13 AM, Boris Brezillon
<boris.brezillon@...e-electrons.com> wrote:
> Correct me if I'm wrong, but the main problem here is that, when we try
> to detect the initial regulator state, we ran into a "missing entry in
> the duty-cycle <-> voltage table" error, which then triggers an -EINVAL
> error preventing the PWM regulator probe to succeed.
>
> Of course, adding an entry for the 0% dutycle case would solve the
> issue, but I wonder if we should not allow "unknown value" at probe
> time, and let the regulator user set the voltage output when it claims
> it.
>
> Another option would be to fake a valid value in this case (choose the
> closest entry in the voltage table?).

If the goal is to avoid glitching the voltage at bootup, then the
above doesn't really solve it.

For instance, you could have:

0% - 1.5V
100% - 0.8V
When configured as input: 1.1V
Max useful value: 1.2V

So if firmware doesn't touch the PWM regulator then that means you're
booting up at 1.1V.

If you read out the PWM itself, it will claim that it's running at 0%.
While that's true, that doesn't mean that the voltage on the system is
actually 1.5V because at boot the system had configured the pinmux as
GPIO input.  ...so it's actually 1.1V because the PWM isn't actually
controlling the pins.

So if you want to avoid glitching the line then you want to make sure
that you properly init to 1.1V, _not_ to 1.5V.

In the case above, it's possible that 1.5V isn't really so great for
the hardware lifespan because 1.2V is the maximum useful value.  You
could argue that the hardware is badly designed in this case, but I
have certainly seen boards designed where the maximum achievable value
is higher than the maximum "safe" value.

-Doug