linux-kernel - Re: [PATCH] clk: qcom: gcc-sdm660: Replace usage of parent

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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <YSZ7Qi93T4u8cKH/@builder.lan>
Date:   Wed, 25 Aug 2021 12:17:54 -0500
From:   Bjorn Andersson <bjorn.andersson@...aro.org>
To:     AngeloGioacchino Del Regno 
        <angelogioacchino.delregno@...ainline.org>
Cc:     Marijn Suijten <marijn.suijten@...ainline.org>,
        Michael Turquette <mturquette@...libre.com>,
        Stephen Boyd <sboyd@...nel.org>, linux-arm-msm@...r.kernel.org,
        linux-clk@...r.kernel.org, linux-kernel@...r.kernel.org,
        Konrad Dybcio <konrad.dybcio@...ainline.org>
Subject: Re: [PATCH] clk: qcom: gcc-sdm660: Replace usage of parent_names

On Wed 25 Aug 05:39 CDT 2021, AngeloGioacchino Del Regno wrote:

> Il 25/08/21 00:38, Bjorn Andersson ha scritto:
> > On Tue 24 Aug 13:46 PDT 2021, Marijn Suijten wrote:
> > 
> > > Hi Bjorn,
> > > 
> > > Thanks for this cleanup, that's needed and much appreciated!
> > > 
> > > On 8/24/21 5:06 PM, Bjorn Andersson wrote:
> > > > Using parent_data and parent_hws, instead of parent_names, does protect
> > > > against some cases of incompletely defined clock trees. While it turns
> > > > out that the bug being chased this time was totally unrelated, this
> > > > patch converts the SDM660 GCC driver to avoid such issues.
> > > > 
> > > > Signed-off-by: Bjorn Andersson <bjorn.andersson@...aro.org>
> > > 
> > > 
> > > Tested-by: Marijn Suijten <marijn.suijten@...ainline.org>
> > > 
> > > On the Sony Xperia XA2 Ultra, bar the necessary change in the 14NM DSI PHY
> > > driver commented below.
> > > 
> > > > [..]
> > > > -
> > > > -static struct clk_fixed_factor xo = {
> > > > -	.mult = 1,
> > > > -	.div = 1,
> > > > -	.hw.init = &(struct clk_init_data){
> > > > -		.name = "xo",
> > > > -		.parent_names = (const char *[]){ "xo_board" },
> > > > -		.num_parents = 1,
> > > > -		.ops = &clk_fixed_factor_ops,
> > > > -	},
> > > > -};
> > > 
> > > 
> > > Removing the global "xo" clock makes it so that our 14nm DSI PHY does not
> > > have a parent clock anymore, as the clock is called "xo_board" nowadays
> > > ("xo" in the position of fw_name is, as you know, only local to this driver
> > > because it is named that way in the clock-names property). We (SoMainline)
> > > suffer the same DSI PHY hardcoding issue on many other boards and are at
> > > this point investigating whether to provide &xo_board in DT like any other
> > > sane driver.  Do you happen to know if work is already underway to tackle
> > > this?
> > > 
> > 
> > As far as I can tell most other platforms doesn't define "xo" either.
> > E.g. according to debugfs dsi0vco_clk doesn't have a parent on sdm845...
> > 
> > Sounds like we should update the dsi phys to specify a fw_name and
> > update binding and dts to provide this...
> > 
> > 
> > Does this cause a noticeable regression or it's just that we have a
> > dangling clock?
> > 
> 
> Both, actually... but sincerely I would be more for updating the DSI PHY
> drivers instead of keeping a "mock" crystal clock in there (since we do
> always specify one in DT), also because, as Marijn pointed out and as I
> can also confirm, we're seeing the same situation on multiple platforms.
> 
> That would allow us to solve the issue simply with DT, and would make us
> able to switch platforms one by one to the RPM/RPMh XO in a perfect future
> where we will be able to perform XO shutdown on selected platforms.
> 

Fixing the DSI PHY to properly acquire the reference clock using
.fw_name is the right solution in the end. But afaict sdm845, sm8150 and
sm8250 doesn't have a "xo" clock.

So that's why I'm wondering if there's a functional regression caused by
this...and hence if I need to respin this patch with the clock
remaining.

> > > >    static struct clk_alpha_pll gpll0_early = {
> > > >    	.offset = 0x0,
> > > >    	.regs = clk_alpha_pll_regs[CLK_ALPHA_PLL_TYPE_DEFAULT],
> > > > @@ -158,7 +35,9 @@ static struct clk_alpha_pll gpll0_early = {
> > > >    		.enable_mask = BIT(0),
> > > >    		.hw.init = &(struct clk_init_data){
> > > >    			.name = "gpll0_early",
> > > > -			.parent_names = (const char *[]){ "xo" },
> > > > +			.parent_data = &(const struct clk_parent_data){
> > > > +				.fw_name = "xo",
> > > > +			},
> > > 
> > > 
> > > I wish we could use .parent_names for a list of .fw_name's too
> > 
> > Afaict specifying "name" in struct clk_parent_data is the same as using
> > parent_names. But I'm not up to speed on the details of how to migrate
> > the dsi phys.
> > 
> > > > [..]
> > > > @@ -265,7 +270,7 @@ static struct clk_rcg2 blsp1_qup1_i2c_apps_clk_src = {
> > > >    	.freq_tbl = ftbl_blsp1_qup1_i2c_apps_clk_src,
> > > >    	.clkr.hw.init = &(struct clk_init_data){
> > > >    		.name = "blsp1_qup1_i2c_apps_clk_src",
> > > > -		.parent_names = gcc_parent_names_xo_gpll0_gpll0_early_div,
> > > > +		.parent_data = gcc_parent_data_xo_gpll0_gpll0_early_div,
> > > >    		.num_parents = 3,
> > > 
> > > 
> > > How about using ARRAY_SIZE(gcc_parent_data_xo_gpll0_gpll0_early_div) now?
> > > Same for every other occurrence of this pattern.
> > > 
> > 
> > I omitted that because it felt unrelated to the change I was doing, but
> > it could certainly be done.
> > 
> 
> Totally fair and I totally agree.
> 
> By the way,
> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@...ainline.org>
> 

Thanks,
Bjorn