Self-NAK Re: [PATCH] fwts/madt: Add processor UID checking to madt tests

[Prarit Bhargava]

On 07/22/2016 10:34 AM, Prarit Bhargava wrote:
> The current madt test does not do any processor UID comparisons.  They are
> marked as TODOs in the file.
> 
> This patchset implements two ACPI searches (one for old-style Processor
> Declaration operator, and another for the new Processor Device operator)
> that populate a list of UID entries, which can be queried for each MADT
> struct's UID.

Self-NAK.  While the UID code is correct the way I've handled the LSAPIC is
not.  There are three fields to examine in the LSAPIC table, the
acpi_processor_id, the uid_value, and its string representation uid_string.

acpi_processor_id, uid_value, and atoi(uid_string) should all evaluate to
the same value for a given Processor Device operator.  However, that
is NOT true for older tables with Processor Declaration operators.

I'll have to rethink this patch to get the LSAPIC evaluation correct.  It might
be as simple as doing something like:

	madt_find_processor_uid(acpi_processor_id);
	if ((acpi_processor_id == uid_value)) {
		if (uid_value == atoi(uid_string))
			madt_find_processor_uid(uid_value);
		else
			fwts_failed();
	} else
		fwts_failed();

Also ... I'm not sure I agree with this TODO comment in the LSAPIC code:

        /*
         * TODO: should the processor ID field be zero?  The use of
         * the Processor object has been deprecated in 6.0, and this
         * field is used to match this local SAPIC to the processor
         * via the ID.  This has been replaced, I believe, with the
         * processor device object _UID result.  On the other hand,
         * perhaps older tables are still using Processor objects....
         */

I think the above comment may come from the uid_string length being
greater or equal to one (this allows for the string to be empty and null
terminated), not uid_value being greater than or equal to one (see ACPI 6.0
Specification Table 5-56 Processor Local SAPIC Structure).

P.