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: <13721273.q1HcHZAhdQ@phil>
Date:   Tue, 13 Dec 2016 18:48:50 +0100
From:   Heiko Stuebner <heiko@...ech.de>
To:     Brian Norris <briannorris@...omium.org>
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

Am Mittwoch, 7. Dezember 2016, 09:09:17 CET schrieb Brian Norris:
> 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.

I was scratching my head for a bit where this was affecting the evb, until I 
found the include at the end of patch5 :-) .

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

Yep, it was at least booting :-) . I guess I should wire it up again. My shiny 
new Gru somehow did take up its space recently.

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

That somehow sounds unrelated, as this patch only touches gru stuff anyway. So 
if the evb breaks, it would do so after patch5 already.


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

So I guess going forward we could do, describe the evb pwm regulators (in 
disabled state), add general OPPs, add gru with pwm regulators?

I'll try to hook up my evb and check on the pwm-regulators in the schematics 
this week.


Heiko