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]

Date:   Mon, 19 Sep 2016 20:31:07 +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 11:12:12 -0700
Doug Anderson <dianders@...omium.org> wrote:

> Hi,
> 
> On Mon, Sep 19, 2016 at 11:06 AM, Boris Brezillon
> <boris.brezillon@...e-electrons.com> wrote:
> > On Mon, 19 Sep 2016 10:52:51 -0700
> > Doug Anderson <dianders@...omium.org> wrote:
> >  
> >> Hi,
> >>
> >> On Mon, Sep 19, 2016 at 10:48 AM, Boris Brezillon
> >> <boris.brezillon@...e-electrons.com> wrote:  
> >> > 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).  
> >>
> >> Such a solution is achievable with the pinctrl APIs pretty easily.
> >> You might not be able to use the automatic "init" state but you can do
> >> something similar and switch to an "active" state once the PWM is
> >> actually turned on the first time.  
> >
> > But is it really the case here (I don't see any code requesting a
> > specific pinmux depending on the PWM state)?  
> 
> It is not happening right now as far as I know.  ...but that's a bug.

Okay.

> 
> > Anyway, we really need to handle this case, we should define the
> > typical voltage when the PWM is disabled. Same as what you suggested
> > with voltage-when-input, but with a different naming (since the concept
> > of pinmux is PWM hardware/driver specific).
> >
> >         voltage-when-pwm-disabled = <...>;  
> 
> Voltage when disabled and voltage when input are two different states.
> A disabled PWM will typically either drive high or low (depending on
> where it was when you turned it off).  Not all "disabled" states will
> mean that the pin is configured as an input.

Well, my point was that, from the regulator PoV, a PWM is either
enabled or disabled. The pinmux config when the PWM is disabled
depends on the PWM driver/hardware, and I don't think it's a good idea
to expose this information at the regulator level, hence the name
"voltage-when-pwm-disabled". Anyway, let's stop bikeshedding, no
matter the name, I think we both agree that a new DT property is needed
to handle this case :-).