From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tim Deegan Subject: Re: [PATCH] arm: Use HTPIDR to point to per-CPU state Date: Fri, 30 Mar 2012 17:37:30 +0100 Message-ID: <20120330163730.GC90203@ocelot.phlegethon.org> References: <1333124012.15932.118.camel@zakaz.uk.xensource.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Content-Disposition: inline In-Reply-To: <1333124012.15932.118.camel@zakaz.uk.xensource.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Ian Campbell Cc: "xen-devel@lists.xen.org" , Stefano Stabellini List-Id: xen-devel@lists.xenproject.org At 17:13 +0100 on 30 Mar (1333127612), Ian Campbell wrote: > > +DECLARE_PER_CPU(unsigned int, cpu_id); > > +#define get_processor_id() (this_cpu(cpu_id)) > > +#define set_processor_id(id) do { \ > > + WRITE_CP32(__per_cpu_offset[cpuid], HTPIDR); \ > > + this_cpu(cpu_id) = (id); \ > > This macro uses id, cpu_id and cpuid all at the same time... > > The one I'm not really sure about is cpuid, where did he come from? > Looks like it might be a local variable in the two places which call > set_processor_id, and also happens to be the id argument in one of those > cases (the other using literal 0). Yes, that's a silly mistake that just happens to be OK in all callers. Yet another reason to use static inlines rather than macros. :) Should I resubmit with s/cpuid/id/ or can you fix up as you apply? Tim.