From: Ingo Molnar <mingo@elte.hu>
To: Len Brown <lenb@kernel.org>
Cc: Suresh Siddha <suresh.b.siddha@intel.com>,
linux-acpi@vger.kernel.org, venkatesh.pallipadi@intel.com,
hpa@linux.intel.com, steiner@sgi.com
Subject: Re: [patch] x86, acpi: add support for x2apic ACPI extensions
Date: Wed, 8 Apr 2009 18:00:32 +0200 [thread overview]
Message-ID: <20090408160032.GB16759@elte.hu> (raw)
In-Reply-To: <alpine.LFD.2.00.0903271816420.26419@localhost.localdomain>
* Len Brown <lenb@kernel.org> wrote:
>
> On Wed, 25 Mar 2009, Suresh Siddha wrote:
>
> > All logical processors with APIC ID values of 255 and greater will have their
> > APIC reported through Processor X2APIC structure (type-9 entry type) and all
> > logical processors with APIC ID less than 255 will have their APIC reported
> > through legacy Processor Local APIC (type-0 entry type) only. This is the
> > same case even for NMI structure reporting.
> >
> > The Processor X2APIC Affinity structure provides the association between the
> > X2APIC ID of a logical processor and the proximity domain to which the logical
> > processor belongs.
> >
> > For OSPM, Procssor IDs outside the 0-254 range are to be declared as Device()
> > objects in the ACPI namespace.
> >
> > Add support for these x2apic ACPI extensions.
> >
> > Signed-off-by: Suresh Siddha <suresh.b.siddha@intel.com>
> > ---
> >
> > Index: tip/arch/x86/kernel/acpi/boot.c
> > ===================================================================
> > --- tip.orig/arch/x86/kernel/acpi/boot.c
> > +++ tip/arch/x86/kernel/acpi/boot.c
> > @@ -230,6 +230,35 @@ static void __cpuinit acpi_register_lapi
> > }
> >
> > static int __init
> > +acpi_parse_x2apic(struct acpi_subtable_header * header, const unsigned long end)
> > +{
> > + struct acpi_madt_local_x2apic *processor = NULL;
> > +
> > + processor = (struct acpi_madt_local_x2apic *)header;
> > +
> > + if (BAD_MADT_ENTRY(processor, end))
> > + return -EINVAL;
> > +
> > + acpi_table_print_madt_entry(header);
> > +
> > +#ifdef CONFIG_X86_X2APIC
> > + /*
> > + * We need to register disabled CPU as well to permit
> > + * counting disabled CPUs. This allows us to size
> > + * cpus_possible_map more accurately, to permit
> > + * to not preallocating memory for all NR_CPUS
> > + * when we use CPU hotplug.
> > + */
> > + acpi_register_lapic(processor->local_apic_id, /* APIC ID */
> > + processor->lapic_flags & ACPI_MADT_ENABLED);
> > +#else
> > + printk(KERN_WARNING PREFIX "x2apic entry ignored\n");
> > +#endif
> > +
> > + return 0;
> > +}
> > +
> > +static int __init
> > acpi_parse_lapic(struct acpi_subtable_header * header, const unsigned long end)
> > {
> > struct acpi_madt_local_apic *processor = NULL;
> > @@ -289,6 +318,24 @@ acpi_parse_lapic_addr_ovr(struct acpi_su
> > }
> >
> > static int __init
> > +acpi_parse_x2apic_nmi(struct acpi_subtable_header * header, const unsigned long end)
> > +{
> > + struct acpi_madt_local_x2apic_nmi *x2apic_nmi = NULL;
> > +
> > + x2apic_nmi = (struct acpi_madt_local_x2apic_nmi *)header;
> > +
> > + if (BAD_MADT_ENTRY(x2apic_nmi, end))
> > + return -EINVAL;
> > +
> > + acpi_table_print_madt_entry(header);
> > +
> > + if (x2apic_nmi->lint != 1)
> > + printk(KERN_WARNING PREFIX "NMI not connected to LINT 1!\n");
> > +
> > + return 0;
> > +}
> > +
> > +static int __init
> > acpi_parse_lapic_nmi(struct acpi_subtable_header * header, const unsigned long end)
> > {
> > struct acpi_madt_local_apic_nmi *lapic_nmi = NULL;
> > @@ -816,9 +863,12 @@ static int __init acpi_parse_madt_lapic_
> > count = acpi_table_parse_madt(ACPI_MADT_TYPE_LOCAL_SAPIC,
> > acpi_parse_sapic, MAX_APICS);
> >
> > - if (!count)
> > + if (!count) {
> > + count = acpi_table_parse_madt(ACPI_MADT_TYPE_LOCAL_X2APIC,
> > + acpi_parse_x2apic, MAX_APICS);
> > count = acpi_table_parse_madt(ACPI_MADT_TYPE_LOCAL_APIC,
> > acpi_parse_lapic, MAX_APICS);
>
> I'm not fond of the idiom
>
> count = a();
> count = b();
>
> if (count)...
>
> here and below.
>
> if we really don't care if the x2apic parse routines return,
> and we always care what the traditional apic parse routines return,
> we should have
>
> a();
> count = b();
> ...
>
> Ingo, this one is probably more ACPI than it is x86 -- shall I handle it?
Sure, please do.
Ingo
next prev parent reply other threads:[~2009-04-08 16:00 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-03-25 20:43 [patch] x86, acpi: add support for x2apic ACPI extensions Suresh Siddha
2009-03-27 22:20 ` Len Brown
2009-04-08 16:00 ` Ingo Molnar [this message]
2009-03-27 22:24 ` Len Brown
2009-03-30 21:55 ` Suresh Siddha
2009-04-04 0:11 ` Len Brown
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=20090408160032.GB16759@elte.hu \
--to=mingo@elte.hu \
--cc=hpa@linux.intel.com \
--cc=lenb@kernel.org \
--cc=linux-acpi@vger.kernel.org \
--cc=steiner@sgi.com \
--cc=suresh.b.siddha@intel.com \
--cc=venkatesh.pallipadi@intel.com \
/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