LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: James Bottomley <James.Bottomley@HansenPartnership.com>
To: Ingo Molnar <mingo@elte.hu>
Cc: Thomas Gleixner <tglx@linutronix.de>,
	linux-kernel <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] fix ACPI induced voyager compile failure
Date: Fri, 31 Oct 2008 12:42:02 -0500	[thread overview]
Message-ID: <1225474922.3264.2.camel@localhost.localdomain> (raw)
In-Reply-To: <20081030221645.GL30303@elte.hu>

On Thu, 2008-10-30 at 23:16 +0100, Ingo Molnar wrote: 
> * James Bottomley <James.Bottomley@HansenPartnership.com> wrote:
> 
> > On Thu, 2008-10-30 at 22:58 +0100, Ingo Molnar wrote:
> > > * James Bottomley <James.Bottomley@HansenPartnership.com> wrote:
> > > 
> > > > >From c339b7cdc39399855ec07dfbff67304f9c7fa49a Mon Sep 17 00:00:00 2001
> > > > From: James Bottomley <James.Bottomley@HansenPartnership.com>
> > > > Date: Wed, 29 Oct 2008 10:58:13 -0500
> > > > Subject: [VOYAGER] x86: don't pull asm/acpi.h into fixmap_32.h
> > > > 
> > > > If it's not needed it causes compile failures.
> > > > 
> > > > Signed-off-by: James Bottomley <James.Bottomley@HansenPartnership.com>
> > > > ---
> > > >  arch/x86/include/asm/fixmap_32.h |    2 ++
> > > >  1 files changed, 2 insertions(+), 0 deletions(-)
> > > > 
> > > > diff --git a/arch/x86/include/asm/fixmap_32.h b/arch/x86/include/asm/fixmap_32.h
> > > > index 09f29ab..c3302ee 100644
> > > > --- a/arch/x86/include/asm/fixmap_32.h
> > > > +++ b/arch/x86/include/asm/fixmap_32.h
> > > > @@ -25,7 +25,9 @@ extern unsigned long __FIXADDR_TOP;
> > > >  
> > > >  #ifndef __ASSEMBLY__
> > > >  #include <linux/kernel.h>
> > > > +#ifdef CONFIG_ACPI
> > > >  #include <asm/acpi.h>
> > > > +#endif
> > > 
> > > hm, that's quite ugly - such headers are supposed to be safe even if 
> > > CONFIG_APIC is not turned on.
> > > 
> > > What kind of compiler failures are you getting, could you send the 
> > > .config that triggers it? I'm curious what the real cause of the build 
> > > failure is - the #ifdef you are adding seems to fix a symptom, not a 
> > > real bug - and maybe we can do a better fix.
> > 
> > It's the problem of voyager wanting its own definition of
> > phys_cpu_present_map.  acpi.h pulls in mpspec.h which contaminates the
> > voyager_smp.c build.
> 
> i guess voyager could use physid_mask_t just fine?
> 
> physid_mask_t is MAX_APICS derived - but it should work out fine 
> because AFAICS voyager has a maximum of 4 cpus (but definitely less 
> than say 32), while MAX_APICS never goes below 256.

Voyager has a max of 32 actually. The CPU numbering is also fixed and
identifies the processor position (for FRU replacement), so the physical
map is what we use throughout the code.  The problem with the definition
is that it makes a rather pointless distinction between physical and
logical map types ... so there'd be a lot of code churn.   It would be
really nice if physmask_t and cpumask_t could become the same type ...
then we could do all this and no-one would notice.

James



  reply	other threads:[~2008-10-31 22:01 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-10-30 21:01 James Bottomley
2008-10-30 21:58 ` Ingo Molnar
2008-10-30 22:04   ` James Bottomley
2008-10-30 22:16     ` Ingo Molnar
2008-10-31 17:42       ` James Bottomley [this message]
2008-11-03 10:02         ` Ingo Molnar

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=1225474922.3264.2.camel@localhost.localdomain \
    --to=james.bottomley@hansenpartnership.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=tglx@linutronix.de \
    --subject='Re: [PATCH] fix ACPI induced voyager compile failure' \
    /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

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).