From: mark.rutland@arm.com (Mark Rutland)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCHv3 2/5] arm64: cpuinfo: record cpu system register values
Date: Fri, 27 Jun 2014 17:34:11 +0100 [thread overview]
Message-ID: <20140627163411.GL7262@leverpostej> (raw)
In-Reply-To: <20140627153444.GB15775@arm.com>
On Fri, Jun 27, 2014 at 04:34:44PM +0100, Will Deacon wrote:
> Hi Mark,
Hi Will,
> On Thu, Jun 26, 2014 at 04:18:43PM +0100, Mark Rutland wrote:
> > Several kernel subsystems need to know details about CPU system register
> > values, sometimes for CPUs other than that they are executing on. Rather
> > than hard-coding system register accesses and cross-calls for these
> > cases, this patch adds logic to record various system register values at
> > boot-time. This may be used for feature reporting, firmware bug
> > detection, etc.
> >
> > Separate hooks are added for the boot and hotplug paths to enable
> > one-time intialisation and cold/warm boot value mismatch detection in
> > later patches.
>
> [...]
>
> > +void cpuinfo_store_cpu(void)
> > +{
> > + unsigned int cpu = smp_processor_id();
> > + struct cpuinfo_arm64 *info = &per_cpu(cpu_data, cpu);
>
> this_cpu_ptr?
Sure.
>
> > + __cpuinfo_store_cpu(info);
> > +}
> > +
> > +void __init cpuinfo_store_boot_cpu(void)
> > +{
> > + unsigned int cpu = smp_processor_id();
> > + struct cpuinfo_arm64 *info = &per_cpu(cpu_data, cpu);
> > + __cpuinfo_store_cpu(info);
>
> This looks familiar. Can you just call cpuinfo_store_cpu here, or even move
> that code into __cpu_info_store_cpu, which will only work if it runs on the
> CPU owning that data anyway.
I can't call cpuinfo_store_cpu() here, as in patch 5 I'll end up doing
erroneous validation of cpu0 against the (not yet initialised) boot cpu
data.
Given the use of this_cpu_ptr, I can get rid of the smp_processor_id()
calls for now, as they're only necessary when reporting to the user. For
patches 4 and 5 I've moved them to cpuinfo_detect_icache_policy() and
cpuinfo_sanity_check().
Thanks,
Mark.
next prev parent reply other threads:[~2014-06-27 16:34 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-06-26 15:18 [PATCHv3 0/5] arm64: handle heterogeneous system register values Mark Rutland
2014-06-26 15:18 ` [PATCHv3 1/5] arm64: add MIDR_EL1 field accessors Mark Rutland
2014-06-27 14:01 ` Will Deacon
2014-06-27 14:06 ` Russell King - ARM Linux
2014-06-27 14:07 ` Will Deacon
2014-06-26 15:18 ` [PATCHv3 2/5] arm64: cpuinfo: record cpu system register values Mark Rutland
2014-06-27 15:34 ` Will Deacon
2014-06-27 16:34 ` Mark Rutland [this message]
2014-06-26 15:18 ` [PATCHv3 3/5] arm64: cpuinfo: print info for all CPUs Mark Rutland
2014-06-27 17:35 ` Ard Biesheuvel
2014-06-26 15:18 ` [PATCHv3 4/5] arm64: cachetype: report weakest cache policy Mark Rutland
2014-06-26 15:18 ` [PATCHv3 5/5] arm64: add runtime system sanity checks Mark Rutland
2014-06-26 20:29 ` Christopher Covington
2014-06-27 8:58 ` Will Deacon
2014-06-27 9:56 ` Mark Rutland
2014-06-27 16:56 ` Christopher Covington
2014-06-27 17:35 ` Mark Rutland
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=20140627163411.GL7262@leverpostej \
--to=mark.rutland@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