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: <YS1lYui5aXadgkEr@Marijn-Arch-PC.localdomain>
Date:   Tue, 31 Aug 2021 01:10:26 +0200
From:   Marijn Suijten <marijn.suijten@...ainline.org>
To:     Stephen Boyd <sboyd@...nel.org>
Cc:     Bjorn Andersson <bjorn.andersson@...aro.org>,
        linux-arm-msm@...r.kernel.org, phone-devel@...r.kernel.org,
        ~postmarketos/upstreaming@...ts.sr.ht,
        AngeloGioacchino Del Regno 
        <angelogioacchino.delregno@...ainline.org>,
        Konrad Dybcio <konrad.dybcio@...ainline.org>,
        Martin Botka <martin.botka@...ainline.org>,
        Jami Kettunen <jami.kettunen@...ainline.org>,
        Pavel Dubrova <pashadubrova@...il.com>,
        Andy Gross <agross@...nel.org>,
        Michael Turquette <mturquette@...libre.com>,
        Rob Clark <robdclark@...il.com>, Sean Paul <sean@...rly.run>,
        David Airlie <airlied@...ux.ie>,
        Daniel Vetter <daniel@...ll.ch>,
        Dmitry Baryshkov <dmitry.baryshkov@...aro.org>,
        Abhinav Kumar <abhinavk@...eaurora.org>,
        Jonathan Marek <jonathan@...ek.ca>,
        Matthias Kaehlcke <mka@...omium.org>,
        Douglas Anderson <dianders@...omium.org>,
        linux-clk@...r.kernel.org, linux-kernel@...r.kernel.org,
        dri-devel@...ts.freedesktop.org, freedreno@...ts.freedesktop.org,
        Stephen Boyd <swboyd@...omium.org>
Subject: Re: [PATCH v2 1/2] drm/msm/dsi: Use "ref" fw clock instead of global
 name for VCO parent

On 2021-08-30 15:53:10, Stephen Boyd wrote:
> Quoting Marijn Suijten (2021-08-30 15:45:42)
> > Hi Stephen,
> > 
> > On 2021-08-30 15:16:13, Stephen Boyd wrote:
> > > Quoting Marijn Suijten (2021-08-30 11:24:44)
> > > > All DSI PHY/PLL drivers were referencing their VCO parent clock by a
> > > > global name, most of which don't exist or have been renamed.  These
> > > > clock drivers seem to function fine without that except the 14nm driver
> > > > for the sdm6xx [1].
> > > > 
> > > > At the same time all DTs provide a "ref" clock as per the requirements
> > > > of dsi-phy-common.yaml, but the clock is never used.  This patchset puts
> > > > that clock to use without relying on a global clock name, so that all
> > > > dependencies are explicitly defined in DT (the firmware) in the end.
> > > > 
> > > > Note that msm8974 is the only board not providing this clock, and
> > > > apq8064 was providing the wrong clock (19.2MHz cxo instead of 27MHz
> > > > pxo).  Both have been been addressed in separate patches that are
> > > > supposed to land well in advance of this patchset.
> > > > 
> > > > Furthermore not all board-DTs provided this clock initially but that
> > > > deficiency has been addressed in followup patches (see the Fixes:
> > > > below).  Those commits seem to assume that the clock was used, while
> > > > nothing in history indicates that this "ref" clock was ever retrieved.
> > > > 
> > > > [1]: https://lore.kernel.org/linux-arm-msm/386db1a6-a1cd-3c7d-a88e-dc83f8a1be96@somainline.org/
> > > > 
> > > > Fixes: 79e51645a1dd ("arm64: dts: qcom: msm8916: Set 'xo_board' as ref clock of the DSI PHY")
> > > > Fixes: 6969d1d9c615 ("ARM: dts: qcom-apq8064: Set 'cxo_board' as ref clock of the DSI PHY")
> > > > Fixes: 0c0e72705a33 ("arm64: dts: sdm845: Set 'bi_tcxo' as ref clock of the DSI PHYs")
> > > > Signed-off-by: Marijn Suijten <marijn.suijten@...ainline.org>
> > > > ---
> > > >  drivers/gpu/drm/msm/dsi/phy/dsi_phy_10nm.c      | 4 +++-
> > > >  drivers/gpu/drm/msm/dsi/phy/dsi_phy_14nm.c      | 4 +++-
> > > >  drivers/gpu/drm/msm/dsi/phy/dsi_phy_28nm.c      | 4 +++-
> > > >  drivers/gpu/drm/msm/dsi/phy/dsi_phy_28nm_8960.c | 4 +++-
> > > >  drivers/gpu/drm/msm/dsi/phy/dsi_phy_7nm.c       | 4 +++-
> > > >  5 files changed, 15 insertions(+), 5 deletions(-)
> > > > 
> > > > diff --git a/drivers/gpu/drm/msm/dsi/phy/dsi_phy_10nm.c b/drivers/gpu/drm/msm/dsi/phy/dsi_phy_10nm.c
> > > > index e46b10fc793a..3cbb1f1475e8 100644
> > > > --- a/drivers/gpu/drm/msm/dsi/phy/dsi_phy_10nm.c
> > > > +++ b/drivers/gpu/drm/msm/dsi/phy/dsi_phy_10nm.c
> > > > @@ -562,7 +562,9 @@ static int pll_10nm_register(struct dsi_pll_10nm *pll_10nm, struct clk_hw **prov
> > > >         char clk_name[32], parent[32], vco_name[32];
> > > >         char parent2[32], parent3[32], parent4[32];
> > > >         struct clk_init_data vco_init = {
> > > > -               .parent_names = (const char *[]){ "xo" },
> > > > +               .parent_data = &(const struct clk_parent_data) {
> > > > +                       .fw_name = "ref",
> > > 
> > > Please also add .name as the old parent_names value so that newer
> > > kernels can be used without having to use new DT.
> > 
> > We discussed that only msm8974 misses this "ref" clock at the time of
> > writing.  Aforementioned Fixes: patches have all been merged about 3
> > years ago, are those DTs still in use with a newer kernel?  I suppose
> > this patch is only backported to kernels including those DT patches, is
> > it reasonable to assume that at least that DT is in use there?
> 
> I have no idea.
> 
> > 
> > Besides, not all clock trees provide this global "xo" or "bi_tcxo" clock
> > in the first place.
> > 
> 
> It doesn't hurt to also specify a .name to help migrate anything else
> over. Unless you're confident it won't cause problems to rely on proper
> DT being used?

I'm 95% sure this shouldn't cause any problems given current DTs and
their history, but that's probably not enough.  This might also impact
DTs that have not yet been upstreamed, but afaik the general stance is
to not care and actually serve as a fair hint/warning before new DTs
make it to the list.

If there is a protocol in place to deprecate, warn, and eventually
remove this reliance on global clock names I'm more than happy to add
.name as a temporary fallback, even if likely unneeded.  Otherwise we
might never get rid of it.

- Marijn

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ