public inbox for linux-acpi@vger.kernel.org
 help / color / mirror / Atom feed
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

  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