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: <YQsguOCjIFZaJSzd@builder.lan>
Date:   Wed, 4 Aug 2021 18:20:24 -0500
From:   Bjorn Andersson <bjorn.andersson@...aro.org>
To:     Sibi Sankar <sibis@...eaurora.org>
Cc:     sboyd@...nel.org, robh+dt@...nel.org, mka@...omium.org,
        viresh.kumar@...aro.org, agross@...nel.org, rjw@...ysocki.net,
        linux-arm-msm@...r.kernel.org, devicetree@...r.kernel.org,
        linux-kernel@...r.kernel.org, linux-pm@...r.kernel.org,
        dianders@...omium.org, tdas@...eaurora.org
Subject: Re: [PATCH 2/4] cpufreq: qcom: Re-arrange register offsets to
 support per core L3 DCVS

On Wed 04 Aug 18:11 CDT 2021, Bjorn Andersson wrote:

> On Thu 29 Jul 13:04 CDT 2021, Sibi Sankar wrote:
> 
> > Qualcomm SoCs (starting with SM8350) support per core voting for L3 cache
> > frequency. So, re-arrange the cpufreq register offsets to allow access for
> > the L3 interconnect to implement per core control. Also prevent binding
> > breakage caused by register offset shuffling by using the SM8250/SM8350
> > EPSS compatible.
> > 
> > Fixes: 7dbd121a2c58 ("arm64: dts: qcom: sc7280: Add cpufreq hw node")
> > Signed-off-by: Sibi Sankar <sibis@...eaurora.org>
> > ---
> >  drivers/cpufreq/qcom-cpufreq-hw.c | 23 +++++++++++++++++++----
> >  1 file changed, 19 insertions(+), 4 deletions(-)
> > 
> > diff --git a/drivers/cpufreq/qcom-cpufreq-hw.c b/drivers/cpufreq/qcom-cpufreq-hw.c
> > index f86859bf76f1..74ef3b38343b 100644
> > --- a/drivers/cpufreq/qcom-cpufreq-hw.c
> > +++ b/drivers/cpufreq/qcom-cpufreq-hw.c
> > @@ -28,6 +28,7 @@ struct qcom_cpufreq_soc_data {
> >  	u32 reg_volt_lut;
> >  	u32 reg_perf_state;
> >  	u8 lut_row_size;
> > +	bool skip_enable;
> 
> This should probably be called "skip_enable_check".
> 
> >  };
> >  
> >  struct qcom_cpufreq_data {
> > @@ -257,19 +258,31 @@ static const struct qcom_cpufreq_soc_data qcom_soc_data = {
> >  	.reg_volt_lut = 0x114,
> >  	.reg_perf_state = 0x920,
> >  	.lut_row_size = 32,
> > +	.skip_enable = false,
> >  };
> >  
> >  static const struct qcom_cpufreq_soc_data epss_soc_data = {
> > +	.reg_freq_lut = 0x0,
> > +	.reg_volt_lut = 0x100,
> > +	.reg_perf_state = 0x220,
> > +	.lut_row_size = 4,
> > +	.skip_enable = true,
> 
> This change is not compatible with existing DTBs.
> 

Continued staring at this after I sent my response, and I'm confused.

You're say in the commit message that SM8350 and beyond needs access to
some registers in the first 0x100 bytes of the register space. So
therefor you're changing the fallback, which is only used for sc7280...

In other words, you break the compatibility with the existing sc7280
dtb and leave sm8350 unchanged - after saying that this change is for
the sake of sm8350.


Lastly, why is "the L3 frequency" an interconnect and not a clock? (And
why don't we make the cpufreq driver a clock-controller for the
platforms that has this?)

Regards,
Bjorn

> Regards,
> Bjorn
> 
> > +};
> > +
> > +static const struct qcom_cpufreq_soc_data epss_sm8250_soc_data = {
> >  	.reg_enable = 0x0,
> >  	.reg_freq_lut = 0x100,
> >  	.reg_volt_lut = 0x200,
> >  	.reg_perf_state = 0x320,
> >  	.lut_row_size = 4,
> > +	.skip_enable = false,
> >  };
> >  
> >  static const struct of_device_id qcom_cpufreq_hw_match[] = {
> >  	{ .compatible = "qcom,cpufreq-hw", .data = &qcom_soc_data },
> >  	{ .compatible = "qcom,cpufreq-epss", .data = &epss_soc_data },
> > +	{ .compatible = "qcom,sm8250-cpufreq-epss", .data = &epss_sm8250_soc_data },
> > +	{ .compatible = "qcom,sm8350-cpufreq-epss", .data = &epss_sm8250_soc_data },
> >  	{}
> >  };
> >  MODULE_DEVICE_TABLE(of, qcom_cpufreq_hw_match);
> > @@ -334,10 +347,12 @@ static int qcom_cpufreq_hw_cpu_init(struct cpufreq_policy *policy)
> >  	data->res = res;
> >  
> >  	/* HW should be in enabled state to proceed */
> > -	if (!(readl_relaxed(base + data->soc_data->reg_enable) & 0x1)) {
> > -		dev_err(dev, "Domain-%d cpufreq hardware not enabled\n", index);
> > -		ret = -ENODEV;
> > -		goto error;
> > +	if (!data->soc_data->skip_enable) {
> > +		if (!(readl_relaxed(base + data->soc_data->reg_enable) & 0x1)) {
> > +			dev_err(dev, "Domain-%d cpufreq hardware not enabled\n", index);
> > +			ret = -ENODEV;
> > +			goto error;
> > +		}
> >  	}
> >  
> >  	qcom_get_related_cpus(index, policy->cpus);
> > -- 
> > The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
> > a Linux Foundation Collaborative Project
> > 

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ