All of lore.kernel.org
 help / color / mirror / Atom feed
From: Myron Stowe <myron.stowe@hp.com>
To: lenb@kernel.org
Cc: aystarik@gmail.com, linux-acpi <linux-acpi@vger.kernel.org>
Subject: [PATCH 0/3] ACPI: Fix for supporting > 256 processor declaration limit
Date: Wed, 22 Oct 2008 13:10:36 -0600	[thread overview]
Message-ID: <1224702636.6784.13.camel@localhost> (raw)


Len, Alexey:

The following three item patch series fixes an issue with the introduction
of > 256 processor declaration support: "Allow processor to be declared with
the Device() instead of Processor()" (git SHA 11bf04c4).

The root issue is in the lsapic mapping logic of drivers/acpi/processor_core.c.
Currently, the logic tries both types of matches irregardless of declaration
type and relies on one failing.  According to the spec - lsapic mapping is
dependent on how the processor object was declared: CPUs declared using the
"Processor" statement should use the Local SAPIC's 'processor_id', and CPUs
declared using the "Device" statement should use the 'uid'.

Reference: Section 8.4 Declaring Processors; Section 5.2.11.13 Local SAPIC
Structure.  "Advanced Configuration and Power Interface Specification",
Revision 3.0b, October 2006.


[PATCH 1/3] disambiguates the processor declaration type that is currently
conflated so that subsequent logic can behave based explicitly on the
declaration's type.  I expect the disambiguation this patch introduces will
also be advantageous when extending the > 256 processor support for x86 via
x2APIC.

[PATCH 2/3] addresses the root issue as stated above.  With respect to this
patch I'm ambivalent about the 'printk' introduced in "map_lsapic_id()" -
perhaps it should be removed?

[PATCH 3/3] is non-functional white space/spelling fixes in the related code. 


While the specific fix is ia64 focused the underlying code affected is common
to both x86 and ia64.  I have tested on the following platform/namespace
combinations:
  ia64 with "Processor" type namespace processor declarations,
  ia64 with "Device" type namespace processor declarations,
  x86 with "Processor" type namespace processor declarations.

Note that this patch series does *not* handle "Device" type processor
declarations that contain a string type _UID object under the processor
device's scope (I am currently not aware of any platforms that have such to
test against).

All comments welcome.

Myron

-- 
Myron Stowe                             HP Open Source & Linux Org


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

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-10-22 19:10 Myron Stowe [this message]
2008-10-22 19:12 ` [PATCH 1/3] ACPI: Disambiguate processor declaration type Myron Stowe
2008-10-24  1:16   ` Zhao Yakui
2008-10-24  3:07     ` Myron Stowe
2008-10-24  5:36       ` Zhao Yakui
2008-10-24 16:41         ` Myron Stowe
2008-10-24 21:23         ` Myron Stowe
2008-10-27  7:42           ` Zhao Yakui
2008-10-27 16:07             ` Bjorn Helgaas
2008-10-22 19:13 ` [PATCH 2/3] ACPI: Behave uniquely based on processor declaration definition type Myron Stowe
2008-10-24 15:56   ` [PATCH 2/3] ACPI: Behave uniquely based on processor declaration John Keller
2008-10-24 17:11     ` Myron Stowe
2008-10-24 18:42       ` [PATCH 2/3] ACPI: Behave uniquely based on processor John Keller
2008-10-24 20:05         ` Myron Stowe
2008-10-27 15:49           ` John Keller
2008-10-22 19:14 ` [PATCH 3/3] ACPI: 80 column adherence and spelling fix (no functional change) Myron Stowe
2008-10-23  5:34 ` [PATCH 0/3] ACPI: Fix for supporting > 256 processor declaration limit Alexey Starikovskiy
2008-10-23 15:48   ` Myron Stowe
2008-10-23  9:32 ` Zhao Yakui
2008-10-23 16:11   ` Myron Stowe
2008-10-24  2:59     ` Zhao Yakui
2008-10-24  4:42       ` Alexey Starikovskiy

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=1224702636.6784.13.camel@localhost \
    --to=myron.stowe@hp.com \
    --cc=aystarik@gmail.com \
    --cc=lenb@kernel.org \
    --cc=linux-acpi@vger.kernel.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.