linux-kernel - Re: [PATCH v2 3/7] drm/msm/dsi: 28nm 8960 PHY: Get ref clock from the DT

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: <CAD=FV=X5r1CCSeTDXy_cYOBDf4ExNe276pFQSC6T+WWg2=SchA@mail.gmail.com>
Date:   Tue, 27 Nov 2018 22:00:50 -0800
From:   Doug Anderson <dianders@...omium.org>
To:     Matthias Kaehlcke <mka@...omium.org>
Cc:     Rob Clark <robdclark@...il.com>, David Airlie <airlied@...ux.ie>,
        Rob Herring <robh+dt@...nel.org>,
        Mark Rutland <mark.rutland@....com>,
        Andy Gross <andy.gross@...aro.org>,
        David Brown <david.brown@...aro.org>,
        Archit Taneja <architt@...eaurora.org>,
        Sean Paul <seanpaul@...omium.org>,
        Rajesh Yadav <ryadav@...eaurora.org>,
        Stephen Boyd <swboyd@...omium.org>,
        Jeykumar Sankaran <jsanka@...eaurora.org>,
        linux-arm-msm <linux-arm-msm@...r.kernel.org>,
        dri-devel <dri-devel@...ts.freedesktop.org>,
        freedreno <freedreno@...ts.freedesktop.org>,
        devicetree@...r.kernel.org, LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v2 3/7] drm/msm/dsi: 28nm 8960 PHY: Get ref clock from the DT

Hi,

On Mon, Nov 26, 2018 at 3:12 PM Matthias Kaehlcke <mka@...omium.org> wrote:
> @@ -409,8 +410,9 @@ static void dsi_pll_28nm_destroy(struct msm_dsi_pll *pll)
>  static int pll_28nm_register(struct dsi_pll_28nm *pll_28nm)
>  {
>         char *clk_name, *parent_name, *vco_name;
> +       const char *ref_clk_name = __clk_get_name(pll_28nm->vco_ref_clk);

IMO for the 28nm PHY driver you should probably make things work OK
even if the "ref" clock wasn't supplied.  In the spirit of the stable
device tree it would be nice (even if nobody actually ships device
trees separate from kernels).  ...and also it makes the whole thing
easier to land.  If you add compatibility here then the code and
device tree patch can go in separately.

Depending on what others think you could potentially spit some type of
warning in the logs if the ref clock wasn't specified though.

-Doug