2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-03-24 14:02:34 +00:00
|
|
|
|
|
|
|
|
|
2014-02-20 15:45:33 +08:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-04-11 10:13:18 +08:00
|
|
|
|
|
|
|
|
|
2016-06-20 13:56:10 +03:00
|
|
|
|
2016-03-02 14:16:25 +08:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2016-05-06 01:27:09 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-12-30 02:44:59 -05:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-02-02 19:48:19 +03:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2007-03-30 14:16:10 -04:00
|
|
|
|
2007-03-11 03:26:14 -04:00
|
|
|
|
2014-05-31 08:15:02 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-03-11 03:26:14 -04:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-02-02 19:48:22 +03:00
|
|
|
|
2005-08-05 00:44:28 -04:00
|
|
|
|
2007-02-02 19:48:22 +03:00
|
|
|
|
|
|
|
|
|
2015-03-24 14:02:34 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-08-05 00:44:28 -04:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2009-03-30 13:55:30 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-03-24 14:02:34 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-03-30 13:55:30 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-02-02 19:48:22 +03:00
|
|
|
|
2005-08-05 00:44:28 -04:00
|
|
|
|
2007-02-02 19:48:22 +03:00
|
|
|
|
|
|
|
|
|
2015-03-24 14:02:34 +00:00
|
|
|
|
|
|
|
|
|
2005-08-05 00:44:28 -04:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2007-02-02 19:48:22 +03:00
|
|
|
|
2005-08-05 00:44:28 -04:00
|
|
|
|
2007-02-02 19:48:22 +03:00
|
|
|
|
|
|
|
|
|
2014-02-20 15:45:33 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-02-02 19:48:22 +03:00
|
|
|
|
|
|
|
|
|
2014-02-20 15:45:33 +08:00
|
|
|
|
|
|
|
|
|
2007-02-02 19:48:22 +03:00
|
|
|
|
2005-08-05 00:44:28 -04:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2007-02-02 19:48:22 +03:00
|
|
|
|
2005-08-05 00:44:28 -04:00
|
|
|
|
2007-02-02 19:48:22 +03:00
|
|
|
|
|
|
|
|
|
2014-02-20 15:45:33 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-08-05 00:44:28 -04:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2007-02-02 19:48:22 +03:00
|
|
|
|
2005-08-05 00:44:28 -04:00
|
|
|
|
2007-02-02 19:48:22 +03:00
|
|
|
|
|
|
|
|
|
2014-02-20 15:45:33 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-03-30 13:55:30 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-02-20 15:45:33 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-08-05 00:44:28 -04:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2007-02-02 19:48:22 +03:00
|
|
|
|
2005-08-05 00:44:28 -04:00
|
|
|
|
2007-02-02 19:48:22 +03:00
|
|
|
|
|
|
|
|
|
2014-02-20 15:45:33 +08:00
|
|
|
|
|
|
|
|
|
2005-08-05 00:44:28 -04:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2007-02-02 19:48:22 +03:00
|
|
|
|
2005-08-05 00:44:28 -04:00
|
|
|
|
2007-02-02 19:48:22 +03:00
|
|
|
|
|
|
|
|
|
2015-03-24 14:02:34 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-08-05 00:44:28 -04:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2007-02-02 19:48:22 +03:00
|
|
|
|
2005-08-05 00:44:28 -04:00
|
|
|
|
2007-02-02 19:48:22 +03:00
|
|
|
|
|
|
|
|
|
2015-03-24 14:02:34 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-08-05 00:44:28 -04:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2007-02-02 19:48:22 +03:00
|
|
|
|
2005-08-05 00:44:28 -04:00
|
|
|
|
2007-02-02 19:48:22 +03:00
|
|
|
|
|
|
|
|
|
2014-02-20 15:45:33 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-08-05 00:44:28 -04:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2015-03-24 14:02:44 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2014-02-20 15:45:33 +08:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-09-09 15:47:28 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-11-26 22:01:13 +08:00
|
|
|
|
2015-09-09 15:47:28 +02:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2007-02-02 19:48:22 +03:00
|
|
|
|
2007-02-10 22:17:07 -05:00
|
|
|
|
2015-09-09 15:47:28 +02:00
|
|
|
|
ACPI / tables: fix acpi_parse_entries_array() so it traverses all subtables
The acpi_parse_entries_array() function currently returns the very first
time there is any error found by one of the callback functions, or if one
of the callbacks returns a non-zero value. However, the ACPI subtables
being traversed could still have valid entries that could be used by one
of the callback functions. And, if the comments are correct, that is
what should happen -- always traverse all of the subtables, calling as
many of the callbacks as possible.
This patch makes the function consistent with its description so that it
will properly invoke all callbacks for all matching entries, for all
subtables, instead of stopping abruptly as it does today.
This does change the semantics of using acpi_parse_entries_array(). In
examining all users of the function, none of them rely on the current
behavior; that is, there appears to be no assumption that either all
subtables are traversed and all callbacks invoked, or that the function
will return immediately on any error from a callback. Each callback
operates independently. Hence, there should be no functional change
due to this change in semantics.
Future patches being prepared will rely on this new behavior; indeed,
they were written assuming the acpi_parse_entries_array() function
operated as its comments describe. For example, a callback that
counts the number of subtables of a specific type can now be assured
that as many subtables as possible have been enumerated.
Signed-off-by: Al Stone <ahs3@redhat.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2016-08-19 18:48:12 -06:00
|
|
|
|
2015-09-09 15:47:28 +02:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2010-02-19 00:09:22 -05:00
|
|
|
|
2009-07-07 23:22:58 -04:00
|
|
|
|
|
|
|
|
|
2015-09-09 15:47:28 +02:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2014-11-26 22:01:13 +08:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2007-02-10 22:17:07 -05:00
|
|
|
|
2014-02-20 15:45:33 +08:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-02-10 22:17:07 -05:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-02-02 19:48:22 +03:00
|
|
|
|
2007-02-10 22:17:07 -05:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2007-02-02 19:48:22 +03:00
|
|
|
|
2007-02-10 22:17:07 -05:00
|
|
|
|
2015-09-09 15:47:28 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-09-22 15:29:25 +03:00
|
|
|
|
ACPI / tables: fix acpi_parse_entries_array() so it traverses all subtables
The acpi_parse_entries_array() function currently returns the very first
time there is any error found by one of the callback functions, or if one
of the callbacks returns a non-zero value. However, the ACPI subtables
being traversed could still have valid entries that could be used by one
of the callback functions. And, if the comments are correct, that is
what should happen -- always traverse all of the subtables, calling as
many of the callbacks as possible.
This patch makes the function consistent with its description so that it
will properly invoke all callbacks for all matching entries, for all
subtables, instead of stopping abruptly as it does today.
This does change the semantics of using acpi_parse_entries_array(). In
examining all users of the function, none of them rely on the current
behavior; that is, there appears to be no assumption that either all
subtables are traversed and all callbacks invoked, or that the function
will return immediately on any error from a callback. Each callback
operates independently. Hence, there should be no functional change
due to this change in semantics.
Future patches being prepared will rely on this new behavior; indeed,
they were written assuming the acpi_parse_entries_array() function
operated as its comments describe. For example, a callback that
counts the number of subtables of a specific type can now be assured
that as many subtables as possible have been enumerated.
Signed-off-by: Al Stone <ahs3@redhat.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2016-08-19 18:48:12 -06:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-09-25 11:11:43 -07:00
|
|
|
|
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>
2016-08-19 18:48:11 -06:00
|
|
|
|
2015-09-09 15:47:28 +02:00
|
|
|
|
2014-11-26 22:01:14 +08:00
|
|
|
|
2015-09-09 15:47:28 +02:00
|
|
|
|
|
|
|
|
|
2014-11-26 22:01:14 +08:00
|
|
|
|
2012-09-25 11:11:43 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-09-09 15:47:28 +02:00
|
|
|
|
2014-11-26 22:01:13 +08:00
|
|
|
|
2012-09-25 11:11:43 -07:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2007-02-02 19:48:22 +03:00
|
|
|
|
2005-08-05 00:44:28 -04:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2014-11-26 22:01:13 +08:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2016-08-19 18:48:13 -06:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
ACPI / tables: fix acpi_parse_entries_array() so it traverses all subtables
The acpi_parse_entries_array() function currently returns the very first
time there is any error found by one of the callback functions, or if one
of the callbacks returns a non-zero value. However, the ACPI subtables
being traversed could still have valid entries that could be used by one
of the callback functions. And, if the comments are correct, that is
what should happen -- always traverse all of the subtables, calling as
many of the callbacks as possible.
This patch makes the function consistent with its description so that it
will properly invoke all callbacks for all matching entries, for all
subtables, instead of stopping abruptly as it does today.
This does change the semantics of using acpi_parse_entries_array(). In
examining all users of the function, none of them rely on the current
behavior; that is, there appears to be no assumption that either all
subtables are traversed and all callbacks invoked, or that the function
will return immediately on any error from a callback. Each callback
operates independently. Hence, there should be no functional change
due to this change in semantics.
Future patches being prepared will rely on this new behavior; indeed,
they were written assuming the acpi_parse_entries_array() function
operated as its comments describe. For example, a callback that
counts the number of subtables of a specific type can now be assured
that as many subtables as possible have been enumerated.
Signed-off-by: Al Stone <ahs3@redhat.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2016-08-19 18:48:12 -06:00
|
|
|
|
2014-11-26 22:01:13 +08:00
|
|
|
|
|
|
|
|
|
2015-09-09 15:47:28 +02:00
|
|
|
|
|
|
|
|
|
2014-11-26 22:01:13 +08:00
|
|
|
|
2015-09-09 15:47:28 +02:00
|
|
|
|
2014-11-26 22:01:13 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-09-09 15:47:28 +02:00
|
|
|
|
2014-11-26 22:01:13 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-12-14 15:04:39 +08:00
|
|
|
|
2014-11-26 22:01:13 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-09-09 15:47:28 +02:00
|
|
|
|
|
|
|
|
|
2014-11-26 22:01:13 +08:00
|
|
|
|
2016-12-14 15:04:39 +08:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-09-09 15:47:28 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2007-02-02 19:48:22 +03:00
|
|
|
|
2013-01-12 15:29:38 +00:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2007-02-10 22:17:07 -05:00
|
|
|
|
2005-08-05 00:44:28 -04:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2007-02-10 21:28:03 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-01-06 16:47:59 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-02-10 21:28:03 -05:00
|
|
|
|
2013-01-12 15:29:38 +00:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2007-02-02 19:48:22 +03:00
|
|
|
|
2007-03-11 03:26:14 -04:00
|
|
|
|
2010-02-19 00:09:22 -05:00
|
|
|
|
2009-07-07 23:22:58 -04:00
|
|
|
|
|
|
|
|
|
2014-01-06 16:43:54 +08:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2007-03-11 03:26:14 -04:00
|
|
|
|
2016-12-14 15:04:39 +08:00
|
|
|
|
2007-03-11 03:26:14 -04:00
|
|
|
|
2016-12-14 15:04:39 +08:00
|
|
|
|
2007-03-11 03:26:14 -04:00
|
|
|
|
2007-02-02 19:48:22 +03:00
|
|
|
|
|
|
|
|
|
2016-12-14 15:04:39 +08:00
|
|
|
|
2007-02-02 19:48:22 +03:00
|
|
|
|
2007-02-10 21:28:03 -05:00
|
|
|
|
2013-12-05 23:42:38 +08:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2007-03-11 03:26:14 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-12-14 15:04:39 +08:00
|
|
|
|
2007-03-11 03:26:14 -04:00
|
|
|
|
2014-02-20 15:45:33 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-12-14 15:04:39 +08:00
|
|
|
|
2007-03-11 03:26:14 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-04-11 10:13:18 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-04-11 10:13:33 +08:00
|
|
|
|
2016-04-11 10:13:18 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-04-11 10:13:33 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-04-11 10:13:18 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-06-20 13:56:10 +03:00
|
|
|
|
2016-04-11 10:13:18 +08:00
|
|
|
|
2016-06-20 13:56:10 +03:00
|
|
|
|
|
|
|
|
|
2016-04-11 10:13:18 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-04-11 10:13:33 +08:00
|
|
|
|
2016-04-11 10:13:18 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-06-20 13:56:11 +03:00
|
|
|
|
2016-04-11 10:13:18 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
x86/boot/e820: Create coherent API function names for E820 range operations
We have these three related functions:
extern void e820_add_region(u64 start, u64 size, int type);
extern u64 e820_update_range(u64 start, u64 size, unsigned old_type, unsigned new_type);
extern u64 e820_remove_range(u64 start, u64 size, unsigned old_type, int checktype);
But it's not clear from the naming that they are 3 operations based around the
same 'memory range' concept. Rename them to better signal this, and move
the prototypes next to each other:
extern void e820__range_add (u64 start, u64 size, int type);
extern u64 e820__range_update(u64 start, u64 size, unsigned old_type, unsigned new_type);
extern u64 e820__range_remove(u64 start, u64 size, unsigned old_type, int checktype);
Note that this improved organization of the functions shows another problem that was easy
to miss before: sometimes the E820 entry type is 'int', sometimes 'unsigned int' - but this
will be fixed in a separate patch.
No change in functionality.
Cc: Alex Thorlton <athorlton@sgi.com>
Cc: Andy Lutomirski <luto@kernel.org>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Brian Gerst <brgerst@gmail.com>
Cc: Dan Williams <dan.j.williams@intel.com>
Cc: Denys Vlasenko <dvlasenk@redhat.com>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Huang, Ying <ying.huang@intel.com>
Cc: Josh Poimboeuf <jpoimboe@redhat.com>
Cc: Juergen Gross <jgross@suse.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Paul Jackson <pj@sgi.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Rafael J. Wysocki <rjw@sisk.pl>
Cc: Tejun Heo <tj@kernel.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Wei Yang <richard.weiyang@gmail.com>
Cc: Yinghai Lu <yinghai@kernel.org>
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2017-01-28 14:19:36 +01:00
|
|
|
|
2016-04-11 10:13:18 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-06-20 13:56:09 +03:00
|
|
|
|
|
|
|
|
|
2016-04-11 10:13:18 +08:00
|
|
|
|
2016-06-20 13:56:09 +03:00
|
|
|
|
2016-04-11 10:13:18 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-04-11 10:13:33 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-04-11 10:13:18 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-04-11 10:13:33 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-04-11 10:13:18 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-04-11 10:13:33 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-04-11 10:13:18 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-04-11 10:13:33 +08:00
|
|
|
|
2016-04-11 10:13:18 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-04-11 10:13:33 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-04-11 10:13:18 +08:00
|
|
|
|
2016-04-11 10:13:33 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-04-11 10:13:18 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-04-11 10:13:33 +08:00
|
|
|
|
2016-04-11 10:13:18 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-02-02 19:48:22 +03:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-08-05 00:44:28 -04:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2009-02-06 14:00:56 -05:00
|
|
|
|
|
|
|
|
|
2014-05-31 08:15:02 +08:00
|
|
|
|
|
|
|
|
|
2017-07-10 15:23:45 +08:00
|
|
|
|
2014-05-31 08:15:02 +08:00
|
|
|
|
|
|
|
|
|
2017-07-10 15:23:45 +08:00
|
|
|
|
2014-05-31 08:15:02 +08:00
|
|
|
|
|
|
|
|
|
2009-02-06 14:00:56 -05:00
|
|
|
|
|
|
|
|
|
2013-12-05 23:42:38 +08:00
|
|
|
|
2016-04-11 10:13:18 +08:00
|
|
|
|
2009-02-06 14:00:56 -05:00
|
|
|
|
2007-03-11 03:26:14 -04:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2007-03-11 03:26:14 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-08-20 16:41:45 -07:00
|
|
|
|
|
|
|
|
|
2007-03-11 03:26:14 -04:00
|
|
|
|
2014-06-13 21:49:58 +02:00
|
|
|
|
|
|
|
|
|
2007-03-11 03:26:14 -04:00
|
|
|
|
2014-02-20 15:45:33 +08:00
|
|
|
|
2007-03-11 03:26:14 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-05-31 08:15:02 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-01-21 17:05:47 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|