From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ian Campbell Subject: Re: [PATCH] arm: Use HTPIDR to point to per-CPU state Date: Fri, 30 Mar 2012 20:35:05 +0100 Message-ID: <1333136105.12209.3.camel@dagon.hellion.org.uk> References: <1333124012.15932.118.camel@zakaz.uk.xensource.com> <20120330163730.GC90203@ocelot.phlegethon.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20120330163730.GC90203@ocelot.phlegethon.org> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Tim Deegan Cc: "xen-devel@lists.xen.org" , Stefano Stabellini List-Id: xen-devel@lists.xenproject.org On Fri, 2012-03-30 at 17:37 +0100, Tim Deegan wrote: > 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? If it's a simple as that I'll fix it as I apply. Ian.