devicetree.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Lee Jones <lee.jones@linaro.org>
To: Viresh Kumar <viresh.kumar@linaro.org>
Cc: linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org, kernel@stlinux.com,
	maxime.coquelin@st.com, linux-pm@vger.kernel.org,
	rjw@rjwysocki.net, devicetree@vger.kernel.org,
	ajitpal.singh@st.com
Subject: Re: [PATCH v6 08/10] cpufreq: st: Provide runtime initialised driver for ST's platforms
Date: Thu, 10 Dec 2015 08:25:18 +0000	[thread overview]
Message-ID: <20151210082518.GD17876@x1> (raw)
In-Reply-To: <20151210020737.GB29459@ubuntu>

On Thu, 10 Dec 2015, Viresh Kumar wrote:

> On 09-12-15, 15:58, Lee Jones wrote:
> > +/*
> > + * Only match on "suitable for ALL versions" entries
> > + *
> > + * This will be used with the BIT() macro.  It sets the
> > + * top bit of a 32bit value and is equal to 0x80000000.
> > + */
> > +#define DEFAULT_VERSION		31
> 
> Okay, I misread it in the earlier version. This looks fine.
> 
> > +static int sti_cpufreq_set_opp_info(void)
> > +{
> 
> > +	sprintf(name, "pcode%d", pcode);
> 
> I would use snprintf here, in case I haven't counted the string
> properly. That should guarantee that we don't access the anything else
> than the 'name' array.

Not sure it's a big problem, unless the PCODE is read incorrectly from
h/w, but okay.

> > +	ret = dev_pm_opp_set_prop_name(dev, name);
> > +	if (ret) {
> > +		dev_err(dev, "Failed to set prop name\n");
> > +		return ret;
> > +	}
> > +
> > +	version[0] = BIT(major);
> > +	version[1] = BIT(minor);
> > +	version[2] = BIT(substrate);
> > +
> > +	ret = dev_pm_opp_set_supported_hw(dev, version, VERSION_ELEMENTS);
> > +	if (ret) {
> > +		dev_err(dev, "Failed to set supported hardware\n");
> > +		return ret;
> > +	}
> > +
> > +	dev_err(dev, "pcode: %d major: %d minor: %d substrate: %d\n",
> > +		pcode, major, minor, substrate);
> > +	dev_err(dev, "version[0]: %x version[1]: %x version[2]: %x\n",
> > +		version[0], version[1], version[2]);
> 
> These aren't errors.. dev_info ?

This is left-over from testing.  Will change.

> > +	return 0;
> > +}
> > +
> 
> > +static int sti_cpufreq_init(void)
> > +{
> > +	int ret;
> > +
> > +	ddata.cpu = get_cpu_device(0);
> > +	if (!ddata.cpu) {
> > +		dev_err(ddata.cpu, "Failed to get device for CPU0\n");
> > +		goto skip_voltage_scaling;
> > +	}
> > +
> > +	if (!of_get_property(ddata.cpu->of_node, "operating-points-v2", NULL)) {
> > +		dev_err(ddata.cpu, "OPP-v2 not supported\n");
> 
> Should be:
>                 dev_dbg(ddata.cpu, "OPP-v2 not supported, skip voltage scaling\n");

It's at least a dev_warn().  I do want this to appear on the bootlog.

> > +		goto skip_voltage_scaling;
> > +	}
> > +
> > +	ret = sti_cpufreq_fetch_syscon_regsiters();
> > +	if (ret)
> > +		goto skip_voltage_scaling;
> > +
> > +	ret = sti_cpufreq_set_opp_info();
> > +	if (ret)
> 
> Shouldn't this be !ret ? You should have jumped on success here.

Good spot.  Last minute change.  Will fix.

> > +		goto register_cpufreq_dt;
> > +
> > +skip_voltage_scaling:
> > +	dev_err(ddata.cpu, "Not doing voltage scaling\n");
> 
> This doesn't look nice as you are adding unnecessary jumps to just
> save on a print message. And because of the earlier suggestion you can
> do:

Actually it only adds one extra goto.  The other three are required
regardless.  And it saves on one whole print and prevents the other
two prints from becoming multi-line.  I think a single goto is worth
skipping that amount of non-sense and it is the latter which is the
greater evil.

I've seen what both methods looks like and chose this one for a
reason. 

> 	ret = sti_cpufreq_set_opp_info();
> 	if (ret)
>                 dev_err(ddata.cpu, "Skip voltage scaling\n");
> 
> > +
> > +register_cpufreq_dt:
> > +	platform_device_register_simple("cpufreq-dt", -1, NULL, 0);
> > +
> > +	return 0;
> > +}
> > +module_init(sti_cpufreq_init);
> > +
> > +MODULE_DESCRIPTION("STMicroelectronics CPUFreq/OPP driver");
> > +MODULE_AUTHOR("Ajitpal Singh <ajitpal.singh@st.com>");
> > +MODULE_AUTHOR("Lee Jones <lee.jones@linaro.org>");
> > +MODULE_LICENSE("GPL v2");

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

  reply	other threads:[~2015-12-10  8:25 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-12-09 15:58 [PATCH v6 00/10] cpufreq: Introduce ST's CPUFreq driver Lee Jones
2015-12-09 15:58 ` [PATCH v6 01/10] ARM: multi_v7_defconfig: Enable ST's PWM driver Lee Jones
2015-12-09 15:58 ` [PATCH v6 02/10] ARM: multi_v7_defconfig: Enable ST's Power Reset driver Lee Jones
2015-12-09 15:58 ` [PATCH v6 03/10] ARM: multi_v7_defconfig: Enable support for PWM Regulators Lee Jones
2015-12-09 15:58 ` [PATCH v6 04/10] ARM: STi: STiH407: Provide generic (safe) DVFS configuration Lee Jones
2015-12-09 15:58 ` [PATCH v6 05/10] ARM: STi: STiH407: Provide CPU with clocking information Lee Jones
2015-12-09 15:58 ` [PATCH v6 06/10] ARM: STi: STiH407: Link CPU with its voltage supply Lee Jones
2015-12-09 15:58 ` [PATCH v6 07/10] ARM: STi: STiH407: Provide CPU with a means to look-up Major number Lee Jones
2015-12-09 15:58 ` [PATCH v6 08/10] cpufreq: st: Provide runtime initialised driver for ST's platforms Lee Jones
2015-12-10  2:07   ` Viresh Kumar
2015-12-10  8:25     ` Lee Jones [this message]
2015-12-10  9:14   ` [PATCH v6.1 " Lee Jones
2015-12-10  9:22     ` Viresh Kumar
2015-12-09 15:58 ` [PATCH v6 09/10] dt: cpufreq: st: Provide bindings for ST's CPUFreq implementation Lee Jones
2015-12-09 15:58 ` [PATCH v6 10/10] MAINTAINERS: Add ST's CPUFreq driver to the STI file list Lee Jones
2015-12-10  2:12 ` [PATCH v6 00/10] cpufreq: Introduce ST's CPUFreq driver Viresh Kumar

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20151210082518.GD17876@x1 \
    --to=lee.jones@linaro.org \
    --cc=ajitpal.singh@st.com \
    --cc=devicetree@vger.kernel.org \
    --cc=kernel@stlinux.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=maxime.coquelin@st.com \
    --cc=rjw@rjwysocki.net \
    --cc=viresh.kumar@linaro.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).