From: Myron Stowe <myron.stowe@hp.com>
To: Zhao Yakui <yakui.zhao@intel.com>
Cc: lenb@kernel.org, aystarik@gmail.com,
linux-acpi <linux-acpi@vger.kernel.org>
Subject: Re: [PATCH 1/3] ACPI: Disambiguate processor declaration type
Date: Thu, 23 Oct 2008 21:07:13 -0600 [thread overview]
Message-ID: <1224817633.6789.41.camel@localhost> (raw)
In-Reply-To: <1224810982.3945.22.camel@yakui_zhao.sh.intel.com>
On Fri, 2008-10-24 at 09:16 +0800, Zhao Yakui wrote:
> On Wed, 2008-10-22 at 13:12 -0600, Myron Stowe wrote:
> > Declaring processors in ACPI namespace can be done using either a "Processor"
> > definition or a "Device" definition (see section 8.4 - Declaring Processors;
> > "Advanced Configuration and Power Interface Specification", Revision 3.0b).
> > Currently the two processor declaration types are conflated.
> In most cases there is no _UID object under the scope of processor
> namespace. So the current source can work well without adding the new
> HID("ACPI_CPU") for processor definition.
>
> If there exists the _UID object under the scope of processor namespace,
> IMO the ProcessorID returned by _UID will have higher priority. In such
> case the patch can't work well.
According to section 5.2.11.13 "Local SAPIC Structure" - Local SAPIC to
processor object association uses the 'ProcessorID' for CPUs declared
with "Processor" statements and Local SAPIC to processor object
association for CPUs declared with "Device" statements use the '_UID'.
There is no "higher priority" - the association is fixed and must take
into account the type of CPU declaration - either "Processor" or
"Device" - to use the appropriate field - either 'ProcessorID' or '_UID'
- for the match.
In example, the combinations of CPU declaration type used in combination
with whether or not the CPU declaration contains a _UID child object are
"Processor" without a _UID child object (which our systems have)
"Processor" with a _UID child object (which our systems have)
"Device" without a _UID child object
"Device" with a _UID child object (which our systems now have)
In the "Processor" declarations the match to the Local SAPIC is based on
the 'ProcessorID' value regardless of whether or not there is a _UID
child object. For "Device" declarations, the match to the Local SAPIC
is based on the '_UID' of the child object - so the third case above
("Device" without a _UID child object) would be illegal.
This patch separates the type of CPU declaration that was encountered in
the namespace (the current code conflated them into a single #define).
The separation enables the mapping logic, that is done later, know
explicitly which CPU declaration type was used so that it can use the
proper field - 'ProcessorID' or '_UID' for the association.
If you do not agree with this interpretation of the spec then please let
me know where you believe I am wrong.
Myron
>
> >
> > This patch disambiguates the processor declaration's definition type enabling
> > subsequent code to behave uniquely based explicitly on the declaration's type.
> >
> > Signed-off-by: Myron Stowe <myron.stowe@hp.com>
> > CC: Alexey Starikovskiy <aystarik@gmail.com>
> >
> > ---
> > drivers/acpi/processor_core.c | 1 +
> > drivers/acpi/scan.c | 2 +-
> > include/acpi/acpi_drivers.h | 1 +
> > 3 files changed, 3 insertions(+), 1 deletion(-)
> >
> > Index: linux-2.6/drivers/acpi/processor_core.c
> > ===================================================================
> > --- linux-2.6.orig/drivers/acpi/processor_core.c 2008-10-16 19:00:37.000000000 -0600
> > +++ linux-2.6/drivers/acpi/processor_core.c 2008-10-21 13:11:00.000000000 -0600
> > @@ -89,6 +89,7 @@ static int acpi_processor_handle_eject(s
> >
> >
> > static const struct acpi_device_id processor_device_ids[] = {
> > + {ACPI_PROCESSOR_OBJECT_HID, 0},
> > {ACPI_PROCESSOR_HID, 0},
> > {"", 0},
> > };
> > Index: linux-2.6/include/acpi/acpi_drivers.h
> > ===================================================================
> > --- linux-2.6.orig/include/acpi/acpi_drivers.h 2008-10-16 18:53:26.000000000 -0600
> > +++ linux-2.6/include/acpi/acpi_drivers.h 2008-10-20 13:23:28.000000000 -0600
> > @@ -41,6 +41,7 @@
> > */
> >
> > #define ACPI_POWER_HID "LNXPOWER"
> > +#define ACPI_PROCESSOR_OBJECT_HID "ACPI_CPU"
> > #define ACPI_PROCESSOR_HID "ACPI0007"
> > #define ACPI_SYSTEM_HID "LNXSYSTM"
> > #define ACPI_THERMAL_HID "LNXTHERM"
> > Index: linux-2.6/drivers/acpi/scan.c
> > ===================================================================
> > --- linux-2.6.orig/drivers/acpi/scan.c 2008-10-16 19:04:58.000000000 -0600
> > +++ linux-2.6/drivers/acpi/scan.c 2008-10-21 13:09:09.000000000 -0600
> > @@ -1025,7 +1025,7 @@ static void acpi_device_set_id(struct ac
> > hid = ACPI_POWER_HID;
> > break;
> > case ACPI_BUS_TYPE_PROCESSOR:
> > - hid = ACPI_PROCESSOR_HID;
> > + hid = ACPI_PROCESSOR_OBJECT_HID;
> > break;
> > case ACPI_BUS_TYPE_SYSTEM:
> > hid = ACPI_SYSTEM_HID;
> >
> >
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
Myron Stowe HP Open Source & Linux Org
next prev parent reply other threads:[~2008-10-24 3:07 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-10-22 19:10 [PATCH 0/3] ACPI: Fix for supporting > 256 processor declaration limit Myron Stowe
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 [this message]
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=1224817633.6789.41.camel@localhost \
--to=myron.stowe@hp.com \
--cc=aystarik@gmail.com \
--cc=lenb@kernel.org \
--cc=linux-acpi@vger.kernel.org \
--cc=yakui.zhao@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