[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <YxGXTs0MO6Sg7nit@hovoldconsulting.com>
Date: Fri, 2 Sep 2022 07:40:30 +0200
From: Johan Hovold <johan@...nel.org>
To: Doug Anderson <dianders@...omium.org>
Cc: Bjorn Andersson <bjorn.andersson@...aro.org>,
Andrew Halaney <ahalaney@...hat.com>,
Mark Brown <broonie@...nel.org>,
Andy Gross <agross@...nel.org>,
AngeloGioacchino Del Regno
<angelogioacchino.delregno@...ainline.org>,
Bhupesh Sharma <bhupesh.sharma@...aro.org>,
Johan Hovold <johan+linaro@...nel.org>,
Konrad Dybcio <konrad.dybcio@...ainline.org>,
Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
Rob Herring <robh+dt@...nel.org>,
Vinod Koul <vkoul@...nel.org>,
"open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS"
<devicetree@...r.kernel.org>,
linux-arm-msm <linux-arm-msm@...r.kernel.org>,
LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v2 0/6] arm64: dts: qcom: Fix broken regulator spec on
RPMH boards
On Thu, Sep 01, 2022 at 05:44:03PM -0700, Doug Anderson wrote:
> Hi,
>
> On Thu, Sep 1, 2022 at 8:52 AM Johan Hovold <johan@...nel.org> wrote:
> >
> > On Wed, Aug 31, 2022 at 07:52:52AM -0700, Doug Anderson wrote:
> > > Hi,
> > >
> > > On Tue, Aug 30, 2022 at 11:47 PM Johan Hovold <johan@...nel.org> wrote:
> > > >
> > > > On Mon, Aug 29, 2022 at 09:49:46AM -0700, Douglas Anderson wrote:
> > > > > Prior to commit efb0cb50c427 ("regulator: qcom-rpmh: Implement
> > > > > get_optimum_mode(), not set_load()") several boards were able to
> > > > > change their regulator mode even though they had nothing listed in
> > > > > "regulator-allowed-modes". After that commit (and fixes [1]) we'll be
> > > > > stuck at the initial mode. Discussion of this (again, see [1]) has
> > > > > resulted in the decision that the old dts files were wrong and should
> > > > > be fixed to fully restore old functionality.
> > > > >
> > > > > This series attempts to fix everyone. I've kept each board in a
> > > > > separate patch to make stable / backports work easier.
> > > >
> > > > Should you also update the bindings so that this can be caught during
> > > > devicetree validation? That is, to always require
> > > > "regulator-allowed-modes" when "regulator-allow-set-load" is specified.
> > >
> > > Yeah, it's probably a good idea. I'm happy to review a patch that does
> > > that. I'm already quite a few patches deep of submitting random
> > > cleanups because someone mentioned it in a code review. ;-) That's
> > > actually how I got in this mess to begin with. The RPMH change was in
> > > response to a request in a different code review. ...and that came
> > > about in a code review that was posted in response to a comment about
> > > how awkward setting regulator loads was... Need to get back to my day
> > > job.
> >
> > Heh.
> >
> > > In any case, I think these dts patches are ready to land now.
> >
> > Yeah, as the old dtbs are now broken with newer kernels these are indeed
> > needed.
>
> With the latest patches in the regulator tree things shouldn't be
> _too_ broken even without the dts files. Essentially things will get
> stuck at their initial mode (HPM). So without these patches things
> should all still boot but could possibly end up at a higher power
> state.
Ok, and there's also a warning during boot when that happens so that
it's not a silent regression?
Johan
Powered by blists - more mailing lists