From: Thomas Gleixner <tglx@linutronix.de>
To: Dou Liyang <douly.fnst@cn.fujitsu.com>
Cc: mingo@kernel.org, peterz@infradead.org, rjw@rjwysocki.net,
hpa@zytor.com, rafael@kernel.org, cl@linux.com, tj@kernel.org,
akpm@linux-foundation.org, rafael.j.wysocki@intel.com,
len.brown@intel.com, izumi.taku@jp.fujitsu.com,
xiaolong.ye@intel.com, x86@kernel.org,
linux-acpi@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2 3/4] acpi: Fix the check handle in case of declaring processors using the Device operator
Date: Wed, 1 Mar 2017 12:12:31 +0100 (CET) [thread overview]
Message-ID: <alpine.DEB.2.20.1703011152310.4005@nanos> (raw)
In-Reply-To: <1487580471-17665-4-git-send-email-douly.fnst@cn.fujitsu.com>
On Mon, 20 Feb 2017, Dou Liyang wrote:
> In ACPI spec, we can declare processors using both Processor and
> Device operator. And before we use the ACPI table, we should check
> the correctness for all processors in ACPI namespace.
>
> But, Currently, the check handle is just include only the processors
> which are declared by Processor operator. It misses the processors
> declared by Device operator.
>
> The patch adds the case of Device operator.
See the comments in the previous mails. They apply here as well.
Though this changelog is actively confusing. The subject line says:
acpi: Fix the check handle in case of declaring processors using the Device
operator
Aside of being a way too long subject, it suggests that there is just a
missing check for the case where a processor is declared via the Device
operator. But that's not what the patch is doing.
It implements the distinction between Device and Processor operator, which
is missing in acpi_processor_ids_walk() right now.
So the proper changelog (if I understand the patch correctly) would be:
Subject: acpi/processor: Implement DEVICE operator for processor enumeration
ACPI allows to declare processors either with the PROCESSOR or with the
DEVICE operator. The current implementation handles only the PROCESSOR
operator.
On a system which uses the DEVICE operator for processor enumeration the
evaluation fails.
Check for the ACPI type of the ACPI handle and evaluate PROCESSOR and
DEVICE types seperately.
Hmm?
> {
> acpi_status status;
> + acpi_object_type acpi_type;
> + unsigned long long uid;
> union acpi_object object = { 0 };
> struct acpi_buffer buffer = { sizeof(union acpi_object), &object };
>
> - status = acpi_evaluate_object(handle, NULL, NULL, &buffer);
> - if (ACPI_FAILURE(status))
> - acpi_handle_info(handle, "Not get the processor object\n");
> - else
> - processor_validated_ids_update(object.processor.proc_id);
> + status = acpi_get_type(handle, &acpi_type);
Shouldn't the status be checked here?
> + switch (acpi_type) {
> + case ACPI_TYPE_PROCESSOR:
> + status = acpi_evaluate_object(handle, NULL, NULL, &buffer);
> + if (ACPI_FAILURE(status))
> + acpi_handle_info(handle, "Not get the processor object\n");
> + else
> + processor_validated_ids_update(
> + object.processor.proc_id);
> + break;
> + case ACPI_TYPE_DEVICE:
> + status = acpi_evaluate_integer(handle, "_UID", NULL, &uid);
> + if (ACPI_FAILURE(status))
> + return false;
> + processor_validated_ids_update(uid);
> + break;
> + default:
> + return false;
This is inconsistent vs. the failure handling in the PROCESSOR and DEVICE
case and the default case does not give any information either.
What about this:
switch (acpi_type) {
case ACPI_TYPE_PROCESSOR:
status = acpi_evaluate_object(handle, NULL, NULL, &buffer);
if (ACPI_FAILURE(status))
goto err;
uid = object.processor.proc_id;
break;
case ACPI_TYPE_DEVICE:
status = acpi_evaluate_integer(handle, "_UID", NULL, &uid);
if (ACPI_FAILURE(status))
goto err;
break;
default:
goto err;
}
processor_validated_ids_update(uid);
return true;
err:
acpi_handle_info(handle, "Invalid processor object\n");
return false;
}
Thanks,
tglx
next prev parent reply other threads:[~2017-03-01 12:34 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-02-20 8:47 [PATCH v2 0/4] Revert works for the mapping of cpuid <-> nodeid Dou Liyang
2017-02-20 8:47 ` [PATCH v2 1/4] Revert"x86/acpi: Set persistent cpuid <-> nodeid mapping when booting" Dou Liyang
2017-03-01 10:51 ` Thomas Gleixner
2017-03-02 7:58 ` Dou Liyang
2017-02-20 8:47 ` [PATCH v2 2/4] Revert"x86/acpi: Enable MADT APIs to return disabled apicids" Dou Liyang
2017-03-01 10:52 ` Thomas Gleixner
2017-03-02 8:02 ` Dou Liyang
2017-02-20 8:47 ` [PATCH v2 3/4] acpi: Fix the check handle in case of declaring processors using the Device operator Dou Liyang
2017-03-01 11:12 ` Thomas Gleixner [this message]
2017-03-02 8:12 ` Dou Liyang
2017-02-20 8:47 ` [PATCH v2 4/4] acpi: Move the verification of duplicate proc_id from booting time to hot-plug time Dou Liyang
2017-03-01 11:26 ` Thomas Gleixner
2017-03-02 8:20 ` Dou Liyang
2017-02-21 1:02 ` [PATCH v2 0/4] Revert works for the mapping of cpuid <-> nodeid Ye Xiaolong
2017-02-21 7:10 ` Ye Xiaolong
2017-02-22 1:56 ` Dou Liyang
2017-03-16 8:14 ` [LKP] " Aaron Lu
2017-03-16 8:28 ` Thomas Gleixner
2017-03-16 8:38 ` Aaron Lu
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=alpine.DEB.2.20.1703011152310.4005@nanos \
--to=tglx@linutronix.de \
--cc=akpm@linux-foundation.org \
--cc=cl@linux.com \
--cc=douly.fnst@cn.fujitsu.com \
--cc=hpa@zytor.com \
--cc=izumi.taku@jp.fujitsu.com \
--cc=len.brown@intel.com \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@kernel.org \
--cc=peterz@infradead.org \
--cc=rafael.j.wysocki@intel.com \
--cc=rafael@kernel.org \
--cc=rjw@rjwysocki.net \
--cc=tj@kernel.org \
--cc=x86@kernel.org \
--cc=xiaolong.ye@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