From: Bjorn Helgaas <bjorn.helgaas@hp.com>
To: Zhao Yakui <yakui.zhao@intel.com>
Cc: Myron Stowe <myron.stowe@hp.com>,
"lenb@kernel.org" <lenb@kernel.org>,
"aystarik@gmail.com" <aystarik@gmail.com>,
linux-acpi <linux-acpi@vger.kernel.org>,
John Keller <jpk@sgi.com>
Subject: Re: [PATCH 1/3] ACPI: Disambiguate processor declaration type
Date: Mon, 27 Oct 2008 10:07:15 -0600 [thread overview]
Message-ID: <200810271007.16758.bjorn.helgaas@hp.com> (raw)
In-Reply-To: <1225093357.5189.47.camel@yakui_zhao.sh.intel.com>
On Monday 27 October 2008 01:42:37 am Zhao Yakui wrote:
> Of course please add some comments that the ACPI ID is always
> obtained from the processor block if the processor object is declared by
> processor.
The code's pretty straightforward already, but maybe comments like
this would address your concern:
if (!strcmp(acpi_device_hid(device), ACPI_PROCESSOR_HID)) {
+ /*
+ * Declared with "Device" statement; match _UID.
+ * Note that we don't handle string _UID yet.
+ */
acpi_evaluate_integer(pr->handle, METHOD_NAME__UID, NULL, &value);
pr->acpi_id = value;
} else {
+ /* Declared with "Processor" statement; match ProcessorID */
acpi_evaluate_object(pr->handle, NULL, NULL, &buffer);
pr->acpi_id = object.processor.proc_id;
}
> If the [_UID] is a string, it should be matched with the
> ACPI processor UID string field of SAPIC table to get the processor ID.
> Now this case is not handled by your patch. Of course maybe there
> doesn't exist such a system. So we can ask the user to send the ACPIdump
> and then add the corresponding support when a string is returned by the
> _UID object. It will be great if we can add the support about this.
That would be nice, but since we don't have a machine to test it with,
Myron would be adding untested code to the kernel, and I don't think
there's much value in that.
Bjorn
next prev parent reply other threads:[~2008-10-27 16: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
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 [this message]
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=200810271007.16758.bjorn.helgaas@hp.com \
--to=bjorn.helgaas@hp.com \
--cc=aystarik@gmail.com \
--cc=jpk@sgi.com \
--cc=lenb@kernel.org \
--cc=linux-acpi@vger.kernel.org \
--cc=myron.stowe@hp.com \
--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 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.