ACPI / tables: fix incorrect counts returned by acpi_parse_entries_array()
The static function acpi_parse_entries_array() is provided an array of type struct acpi_subtable_proc that has a callback function and a count. The count should reflect how many times the callback has been called. However, the current code only increments the 0th element of the array, regardless of the number of entries in the array, or which callback has been invoked. The result is that we know the total number of callbacks made but we cannot determine which callbacks were made, nor how often. The fix is to index into the array of structs and increment the proper counts. There is one place in the x86 code for acpi_parse_madt_lapic_entries() where the counts for each callback are used. If no LAPICs *and* no X2APICs are found, an ENODEV is supposed to be returned; as it stands, the count of X2APICs will always be zero, regardless of what is in the MADT. Should there be no LAPICs, ENODEV will be returned in error, if there are X2APICs in the MADT. Otherwise, there are no other functional consequences of the count being done as it currently is; all other uses simply check that the return value from acpi_parse_entries_array() or passed back via its callers is either non-zero, an error, or in one case just ignored. In future patches, I will also need these counts to be correct; I need to count the number of instances of subtables of certain types within the MADT to determine whether or not an ACPI IORT is required or not, and report when it is not present when it should be. Signed-off-by: Al Stone <ahs3@redhat.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
This commit is contained in:
parent
3eab887a55
commit
fa162a05de
1 changed files with 1 additions and 1 deletions
|
@ -281,7 +281,7 @@ acpi_parse_entries_array(char *id, unsigned long table_size,
|
|||
proc[i].handler(entry, table_end))
|
||||
return -EINVAL;
|
||||
|
||||
proc->count++;
|
||||
proc[i].count++;
|
||||
break;
|
||||
}
|
||||
if (i != proc_num)
|
||||
|
|
Loading…
Reference in a new issue