public inbox for linux-arm-kernel@lists.infradead.org
 help / color / mirror / Atom feed
From: juri.lelli@arm.com (Juri Lelli)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v5 4/8] arm64: parse cpu capacity-dmips-mhz from DT
Date: Wed, 15 Jun 2016 15:48:21 +0100	[thread overview]
Message-ID: <20160615144821.GF5981@e106622-lin> (raw)
In-Reply-To: <20160615134938.GA2282@sirena.org.uk>

On 15/06/16 14:49, Mark Brown wrote:
> On Wed, Jun 15, 2016 at 11:17:53AM +0100, Juri Lelli wrote:
> 
> > +		if (!raw_capacity) {
> > +			raw_capacity = kzalloc(sizeof(*raw_capacity) *
> > +					num_possible_cpus(), GFP_KERNEL);
> 
> kcalloc()?
> 

Right. Will change.

> > +			if (!raw_capacity) {
> > +				pr_err("cpu_capacity: failed to allocate memory"
> > +				       " for raw capacities\n");
> 
> It's normally better to avoid splitting errors message so people can
> grep if they see the error.
> 

Tried to avoid breaking 80 columns. But, we seem to have longer pr_err
strings already. I'll change that.

> > +	} else {
> > +		pr_err("cpu_capacity: missing %s raw capacity "
> > +		       "(fallback to 1024 for all CPUs)\n",
> > +				cpu_node->full_name);
> 
> That's going to complain fairly loudly for all existing DTs isn't it and
> it's kind of redundant if all the cores have the same capacity (which is
> a very common case)?  How about printing an error only if we already
> found one, or printing a single warning at the end if we didn't get
> anything?

Right, I'll change the condition for which pr_err is emitted. I think
the situation for which we care the most about is when we find partial
information in DT.

Thanks,

- Juri

  reply	other threads:[~2016-06-15 14:48 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-06-15 10:17 [PATCH v5 0/8] CPUs capacity information for heterogeneous systems Juri Lelli
2016-06-15 10:17 ` [PATCH v5 1/8] Documentation: arm: define DT cpu capacity-dmips-mhz bindings Juri Lelli
2016-06-15 12:51   ` Vincent Guittot
2016-06-15 14:24     ` Juri Lelli
2016-06-15 14:04   ` Mark Brown
2016-06-15 14:22     ` Juri Lelli
2016-06-15 22:11   ` Rob Herring
2016-06-16  8:20     ` Juri Lelli
2016-06-22 16:51       ` Juri Lelli
2016-06-15 10:17 ` [PATCH v5 2/8] arm: parse cpu capacity-dmips-mhz from DT Juri Lelli
2016-06-15 10:17 ` [PATCH v5 3/8] arm, dts: add TC2 cpu capacity-dmips-mhz information Juri Lelli
2016-06-15 10:17 ` [PATCH v5 4/8] arm64: parse cpu capacity-dmips-mhz from DT Juri Lelli
     [not found]   ` <CADRr18P=EOwpZTc-aS=4cCa8B3ObpuqpbNNv+w5Q4shXD6s7HQ@mail.gmail.com>
2016-06-15 10:25     ` Juri Lelli
2016-06-15 13:49   ` Mark Brown
2016-06-15 14:48     ` Juri Lelli [this message]
2016-06-15 10:17 ` [PATCH v5 5/8] arm64, dts: add Juno cpu capacity-dmips-mhz information Juri Lelli
2016-06-15 10:17 ` [PATCH v5 6/8] arm64, dts: add Juno r2 " Juri Lelli
2016-06-15 10:17 ` [PATCH v5 7/8] arm: add sysfs cpu_capacity attribute Juri Lelli
2016-06-15 10:17 ` [PATCH v5 8/8] arm64: " Juri Lelli

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=20160615144821.GF5981@e106622-lin \
    --to=juri.lelli@arm.com \
    --cc=linux-arm-kernel@lists.infradead.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