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: <20160919194844.0db7b307@bbrezillon>
Date:   Mon, 19 Sep 2016 19:48:44 +0200
From:   Boris Brezillon <boris.brezillon@...e-electrons.com>
To:     Doug Anderson <dianders@...omium.org>
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

On Mon, 19 Sep 2016 10:22:43 -0700
Doug Anderson <dianders@...omium.org> wrote:

> 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.

Oh! I really didn't consider this case when developing the solution. I
was assuming that the firmware/bootloader would configure the PWM
correctly and leave it activating when booting the kernel.

> 
> 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.

The PWM chip has always claimed the pins and muxed them to the PWM IP.
So, this means it's broken from the beginning, and my patch is only
uncovering the problem (unless the pins stay configured as input until
the PWM is enabled, which I'm not sure is the case).

> 
> 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