linux-kernel - Re: [PATCH v7 7/8] clk: qcom: dispcc-sm8250: stop using mmcx regulator

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:   Thu, 14 Oct 2021 17:04:52 -0700
From:   Stephen Boyd <sboyd@...nel.org>
To:     Bjorn Andersson <bjorn.andersson@...aro.org>,
        Dmitry Baryshkov <dmitry.baryshkov@...aro.org>
Cc:     Andy Gross <agross@...nel.org>, Rob Herring <robh+dt@...nel.org>,
        Taniya Das <tdas@...eaurora.org>,
        Jonathan Marek <jonathan@...ek.ca>,
        Michael Turquette <mturquette@...libre.com>,
        linux-arm-msm@...r.kernel.org, devicetree@...r.kernel.org,
        linux-clk@...r.kernel.org,
        Bryan O'Donoghue <bryan.odonoghue@...aro.org>,
        Mark Brown <broonie@...nel.org>,
        Ulf Hansson <ulf.hansson@...aro.org>,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH v7 7/8] clk: qcom: dispcc-sm8250: stop using mmcx regulator

Quoting Dmitry Baryshkov (2021-10-14 02:53:41)
> On 13/10/2021 22:50, Stephen Boyd wrote:
> > Quoting Dmitry Baryshkov (2021-10-07 09:16:13)
> >> On 07/10/2021 18:48, Bjorn Andersson wrote:
> >>> On Sun 29 Aug 08:47 PDT 2021, Dmitry Baryshkov wrote:
> >>>
> >>>> Now as the common qcom clock controller code has been taught about power
> >>>> domains, stop mentioning mmcx supply as a way to power up the clock
> >>>> controller's gdsc.
> >>>>
> >>>> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@...aro.org>
> >>>> Reviewed-by: Bjorn Andersson <bjorn.andersson@...aro.org>
> >>>
> >>> Once we merge these, I expect that the boards will start crashing if
> >>> the kernel is booted using an existing DTB?
> >>>
> >>> Is it okay to just merge the first 6 patches in the series now and
> >>> postpone these two until we've had the dts change sitting for a while?
> >>
> >> Sure it is.
> >>
> > 
> > What's the merge strategy? It goes through arm-soc?
> 
> I think this should go through the clk tree. There is little chance of 
> conflicts.
> 

The other thing that concerns me is that we don't have backwards
compat code. If things are going to start crashing that's not very nice.
Is there some way to make it work with old and new DTB for one release
so that we don't have to worry about this problem?