linux-kernel - Re: [PATCH 8/9] arm64: dts: rockchip: partially describe PWM regulators for Gru

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: <20161207170916.GA84287@google.com>
Date:   Wed, 7 Dec 2016 09:09:17 -0800
From:   Brian Norris <briannorris@...omium.org>
To:     Heiko Stuebner <heiko@...ech.de>
Cc:     linux-rockchip@...ts.infradead.org, linux-kernel@...r.kernel.org,
        Caesar Wang <wxt@...k-chips.com>,
        Doug Anderson <dianders@...omium.org>,
        devicetree@...r.kernel.org, Rob Herring <robh+dt@...nel.org>,
        Stephen Barber <smbarber@...omium.org>,
        linux-arm-kernel@...ts.infradead.org,
        Chris Zhong <zyw@...k-chips.com>
Subject: Re: [PATCH 8/9] arm64: dts: rockchip: partially describe PWM
 regulators for Gru

Hi Heiko,

On Wed, Dec 07, 2016 at 05:48:24PM +0100, Heiko Stuebner wrote:
> Am Donnerstag, 1. Dezember 2016, 18:27:32 CET schrieb Brian Norris:
> > We need to add regulators to the CPU nodes, so cpufreq doesn't think it
> > can crank up the clock speed without changing the voltage. However, we
> > don't yet have the DT bindings to fully describe the Over Voltage
> > Protection (OVP) circuits on these boards. Without that description, we
> > might end up changing the voltage too much, too fast.
> > 
> > Add the pwm-regulator descriptions and associate the CPU OPPs, but leave
> > them disabled.
> > 
> > Signed-off-by: Brian Norris <briannorris@...omium.org>
> 
> is there a specific reason for keeping this change separate?

Maybe not a great one. I figured they were somewhat controversial, so I
at least wanted to split the "cpufreq patches" (i.e., this and the
previous) from the main DTS(I) additions. I also figured we typically
like to keep the base SoC changes separate from the board DTS(I)
changes.

> While it is nice for documentation reasons, as it stands now the previous 
> patch introduces a regression (cpufreq trying to scale without regulators) and 
> immediately fixes it here.

Right. Additionally, as noted on the previous patch, we might do the
same with EVB. But I don't know what the regulators are like for EVB.
This is probably a bigger deal, since EVB has been working (allegedly)
upstream for a while now.

There's no way to split these up without either breaking compilation or
breaking bisectability. For Kevin/Gru, they don't function at all before
this series, so I figured some "settle" time wasn't a huge deal.

> So if you're ok with it, I'd like to merge this one back into the previous 
> patch when applying.

That'd be OK with me, as long as we're also confident about EVB.

Maybe at a minimum, I should just patch in some empty regulator nodes,
so cpufreq doesn't think there's no need to handle voltage.

Brian