ACPI: acpi_processor: Use strscpy instead() of strcpy()

Replace strcpy() with strscpy() in the ACPI processor driver.

strcpy() has been deprecated because it is generally unsafe, so help to
elimina

ACPI: acpi_processor: Use strscpy instead() of strcpy()

Replace strcpy() with strscpy() in the ACPI processor driver.

strcpy() has been deprecated because it is generally unsafe, so help to
eliminate it from the kernel source.

Link: https://github.com/KSPP/linux/issues/88
Signed-off-by: Muhammad Qasim Abdul Majeed <[email protected]>
Link: https://patch.msgid.link/[email protected]
[ rjw: Subject and changelog edits ]
Signed-off-by: Rafael J. Wysocki <[email protected]>

show more ...

ACPI: processor: Reduce the log level of a per-CPU message about idle states

This made the CPU bootup faster, otherwise Linux spends lots
of time to printing nonsense information for each CPU when
t

ACPI: processor: Reduce the log level of a per-CPU message about idle states

This made the CPU bootup faster, otherwise Linux spends lots
of time to printing nonsense information for each CPU when
there are lots of CPUs.

Signed-off-by: Li RongQing <[email protected]>
Link: https://patch.msgid.link/[email protected]
[ rjw: Subject edits ]
Signed-off-by: Rafael J. Wysocki <[email protected]>

show more ...

ACPI: Add post_eject to struct acpi_scan_handler for cpu hotplug

struct acpi_scan_handler has a detach callback that is used to remove
a driver when a bus is changed. When interacting with an eject-

ACPI: Add post_eject to struct acpi_scan_handler for cpu hotplug

struct acpi_scan_handler has a detach callback that is used to remove
a driver when a bus is changed. When interacting with an eject-request,
the detach callback is called before _EJ0.

This means the ACPI processor driver can't use _STA to determine if a
CPU has been made not-present, or some of the other _STA bits have been
changed. acpi_processor_remove() needs to know the value of _STA after
_EJ0 has been called.

Add a post_eject callback to struct acpi_scan_handler. This is called
after acpi_scan_hot_remove() has successfully called _EJ0. Because
acpi_scan_check_and_detach() also clears the handler pointer,
it needs to be told if the caller will go on to call
acpi_bus_post_eject(), so that acpi_device_clear_enumerated()
and clearing the handler pointer can be deferred.
An extra flag is added to flags field introduced in the previous
patch to achieve this.

Signed-off-by: James Morse <[email protected]>
Reviewed-by: Gavin Shan <[email protected]>
Tested-by: Miguel Luis <[email protected]>
Tested-by: Vishnu Pajjuri <[email protected]>
Tested-by: Jianyong Wu <[email protected]>
Acked-by: Rafael J. Wysocki <[email protected]>
Reviewed-by: Hanjun Guo <[email protected]>
Signed-off-by: Jonathan Cameron <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Catalin Marinas <[email protected]>

show more ...

ACPI: processor: Register deferred CPUs from acpi_processor_get_info()

The arm64 specific arch_register_cpu() call may defer CPU registration
until the ACPI interpreter is available and the _STA met

ACPI: processor: Register deferred CPUs from acpi_processor_get_info()

The arm64 specific arch_register_cpu() call may defer CPU registration
until the ACPI interpreter is available and the _STA method can
be evaluated.

If this occurs, then a second attempt is made in
acpi_processor_get_info(). Note that the arm64 specific call has
not yet been added so for now this will be called for the original
hotplug case.

For architectures that do not defer until the ACPI Processor
driver loads (e.g. x86), for initially present CPUs there will
already be a CPU device. If present do not try to register again.

Systems can still be booted with 'acpi=off', or not include an
ACPI description at all as in these cases arch_register_cpu()
will not have deferred registration when first called.

This moves the CPU register logic back to a subsys_initcall(),
while the memory nodes will have been registered earlier.
Note this is where the call was prior to the cleanup series so
there should be no side effects of moving it back again for this
specific case.

[PATCH 00/21] Initial cleanups for vCPU HP.
https://lore.kernel.org/all/ZVyz%[email protected]/
commit 5b95f94c3b9f ("x86/topology: Switch over to GENERIC_CPU_DEVICES")

Signed-off-by: James Morse <[email protected]>
Signed-off-by: Russell King (Oracle) <[email protected]>
Reviewed-by: Gavin Shan <[email protected]>
Tested-by: Miguel Luis <[email protected]>
Tested-by: Vishnu Pajjuri <[email protected]>
Tested-by: Jianyong Wu <[email protected]>
Reviewed-by: Hanjun Guo <[email protected]>
Acked-by: Rafael J. Wysocki <[email protected]>
Co-developed-by: Jonathan Cameron <[email protected]>
Signed-off-by: Jonathan Cameron <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Catalin Marinas <[email protected]>

show more ...

ACPI: processor: Add acpi_get_processor_handle() helper

If CONFIG_ACPI_PROCESSOR provide a helper to retrieve the
acpi_handle for a given CPU allowing access to methods
in DSDT.

Tested-by: Miguel L

ACPI: processor: Add acpi_get_processor_handle() helper

If CONFIG_ACPI_PROCESSOR provide a helper to retrieve the
acpi_handle for a given CPU allowing access to methods
in DSDT.

Tested-by: Miguel Luis <[email protected]>
Reviewed-by: Gavin Shan <[email protected]>
Acked-by: Rafael J. Wysocki <[email protected]>
Signed-off-by: Jonathan Cameron <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Catalin Marinas <[email protected]>

show more ...

ACPI: processor: Move checks and availability of acpi_processor earlier

Make the per_cpu(processors, cpu) entries available earlier so that
they are available in arch_register_cpu() as ARM64 will ne

ACPI: processor: Move checks and availability of acpi_processor earlier

Make the per_cpu(processors, cpu) entries available earlier so that
they are available in arch_register_cpu() as ARM64 will need access
to the acpi_handle to distinguish between acpi_processor_add()
and earlier registration attempts (which will fail as _STA cannot
be checked).

Reorder the remove flow to clear this per_cpu() after
arch_unregister_cpu() has completed, allowing it to be used in
there as well.

Note that on x86 for the CPU hotplug case, the pr->id prior to
acpi_map_cpu() may be invalid. Thus the per_cpu() structures
must be initialized after that call or after checking the ID
is valid (not hotplug path).

Acked-by: Rafael J. Wysocki <[email protected]>
Reviewed-by: Gavin Shan <[email protected]>
Signed-off-by: Jonathan Cameron <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Catalin Marinas <[email protected]>

show more ...

ACPI: processor: Fix memory leaks in error paths of processor_add()

If acpi_processor_get_info() returned an error, pr and the associated
pr->throttling.shared_cpu_map were leaked.

The unwind code

ACPI: processor: Fix memory leaks in error paths of processor_add()

If acpi_processor_get_info() returned an error, pr and the associated
pr->throttling.shared_cpu_map were leaked.

The unwind code was in the wrong order wrt to setup, relying on
some unwind actions having no affect (clearing variables that were
never set etc). That makes it harder to reason about so reorder
and add appropriate labels to only undo what was actually set up
in the first place.

Acked-by: Rafael J. Wysocki <[email protected]>
Reviewed-by: Gavin Shan <[email protected]>
Signed-off-by: Jonathan Cameron <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Catalin Marinas <[email protected]>

show more ...

ACPI: processor: Return an error if acpi_processor_get_info() fails in processor_add()

Rafael observed [1] that returning 0 from processor_add() will result in
acpi_default_enumeration() being calle

ACPI: processor: Return an error if acpi_processor_get_info() fails in processor_add()

Rafael observed [1] that returning 0 from processor_add() will result in
acpi_default_enumeration() being called which will attempt to create a
platform device, but that makes little sense when the processor is known
to be not available. So just return the error code from acpi_processor_get_info()
instead.

Link: https://lore.kernel.org/all/CAJZ5v0iKU8ra9jR+EmgxbuNm=Uwx2m1-8vn_RAZ+aCiUVLe3Pw@mail.gmail.com/ [1]
Suggested-by: Rafael J. Wysocki <[email protected]>
Acked-by: Rafael J. Wysocki <[email protected]>
Reviewed-by: Gavin Shan <[email protected]>
Signed-off-by: Jonathan Cameron <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Catalin Marinas <[email protected]>

show more ...

ACPI: processor: Drop duplicated check on _STA (enabled + present)

The ACPI bus scan will only result in acpi_processor_add() being called
if _STA has already been checked and the result is that the

ACPI: processor: Drop duplicated check on _STA (enabled + present)

The ACPI bus scan will only result in acpi_processor_add() being called
if _STA has already been checked and the result is that the
processor is enabled and present. Hence drop this additional check.

Suggested-by: Rafael J. Wysocki <[email protected]>
Acked-by: Rafael J. Wysocki <[email protected]>
Reviewed-by: Hanjun Guo <[email protected]>
Reviewed-by: Gavin Shan <[email protected]>
Tested-by: Miguel Luis <[email protected]>
Signed-off-by: Jonathan Cameron <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Catalin Marinas <[email protected]>

show more ...

ACPI: processor: Simplify initial onlining to use same path for cold and hotplug

Separate code paths, combined with a flag set in acpi_processor.c to
indicate a struct acpi_processor was for a hotpl

ACPI: processor: Simplify initial onlining to use same path for cold and hotplug

Separate code paths, combined with a flag set in acpi_processor.c to
indicate a struct acpi_processor was for a hotplugged CPU ensured that
per CPU data was only set up the first time that a CPU was initialized.
This appears to be unnecessary as the paths can be combined by letting
the online logic also handle any CPUs online at the time of driver load.

Motivation for this change, beyond simplification, is that ARM64
virtual CPU HP uses the same code paths for hotplug and cold path in
acpi_processor.c so had no easy way to set the flag for hotplug only.
Removing this necessity will enable ARM64 vCPU HP to reuse the existing
code paths.

Acked-by: Rafael J. Wysocki <[email protected]>
Reviewed-by: Hanjun Guo <[email protected]>
Tested-by: Miguel Luis <[email protected]>
Reviewed-by: Gavin Shan <[email protected]>
Reviewed-by: Miguel Luis <[email protected]>
Signed-off-by: Jonathan Cameron <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Catalin Marinas <[email protected]>

show more ...

ACPI: processor: Downgrade Intel _OSC and _PDC messages to debug

Commit 95272641338a ("ACPI: processor: Use _OSC to convey OSPM processor
support information") introduced messages related to determi

ACPI: processor: Downgrade Intel _OSC and _PDC messages to debug

Commit 95272641338a ("ACPI: processor: Use _OSC to convey OSPM processor
support information") introduced messages related to determining processor
support from the firmware.

The UUID 4077A616-290C-47BE-9EBD-D87058713953 and _PDC methods are
only used on Intel platforms, but all X86 platforms emit the messages.

Attempting to evaluate them and showing messages on which are used is
unnecessary for most users. Downgrade the messages to debug instead.

Signed-off-by: Mario Limonciello <[email protected]>
Link: https://patch.msgid.link/[email protected]
Signed-off-by: Rafael J. Wysocki <[email protected]>

show more ...

ACPI: scan: Make acpi_processor_add() check the device enabled bit

Modify acpi_processor_add() return an error if _STA returns the enabled
bit clear for the given processor device, so as to avoid us

ACPI: scan: Make acpi_processor_add() check the device enabled bit

Modify acpi_processor_add() return an error if _STA returns the enabled
bit clear for the given processor device, so as to avoid using processors
that don't decode their resources, as per the ACPI specification. [1]

Link: https://uefi.org/specs/ACPI/6.5/06_Device_Configuration.html#sta-device-status # [1]
Signed-off-by: Rafael J. Wysocki <[email protected]>
Reviewed-by: Jonathan Cameron <[email protected]>

show more ...

ACPI: use %pe for better readability of errors while printing

As %pe is already introduced, it's better to use it in place of (%ld) for
printing errors in logs. It would enhance readability of logs.

ACPI: use %pe for better readability of errors while printing

As %pe is already introduced, it's better to use it in place of (%ld) for
printing errors in logs. It would enhance readability of logs.

Co-developed-by: Maninder Singh <[email protected]>
Signed-off-by: Maninder Singh <[email protected]>
Signed-off-by: Onkarnath <[email protected]>
Reviewed-by: Stanislaw Gruszka <[email protected]>
Signed-off-by: Rafael J. Wysocki <[email protected]>

show more ...

ACPI: Move ACPI_HOTPLUG_CPU to be disabled on arm64 and riscv

Neither arm64 nor riscv support physical hotadd of CPUs that were not
present at boot. For arm64 much of the platform description is in

ACPI: Move ACPI_HOTPLUG_CPU to be disabled on arm64 and riscv

Neither arm64 nor riscv support physical hotadd of CPUs that were not
present at boot. For arm64 much of the platform description is in static
tables which do not have update methods. arm64 does support HOTPLUG_CPU,
which is backed by a firmware interface to turn CPUs on and off.

acpi_processor_hotadd_init() and acpi_processor_remove() are for adding
and removing CPUs that were not present at boot. arm64 systems that do this
are not supported as there is currently insufficient information in the
platform description. (e.g. did the GICR get removed too?)

arm64 currently relies on the MADT enabled flag check in map_gicc_mpidr()
to prevent CPUs that were not described as present at boot from being
added to the system. Similarly, riscv relies on the same check in
map_rintc_hartid(). Both architectures also rely on the weak 'always fails'
definitions of acpi_map_cpu() and arch_register_cpu().

Subsequent changes will redefine ACPI_HOTPLUG_CPU as making possible
CPUs present. Neither arm64 nor riscv support this.

Disable ACPI_HOTPLUG_CPU for arm64 and riscv by removing 'default y' and
selecting it on the other three ACPI architectures. This allows the weak
definitions of some symbols to be removed.

Signed-off-by: James Morse <[email protected]>
Reviewed-by: Shaoqin Huang <[email protected]>
Reviewed-by: Gavin Shan <[email protected]>
Signed-off-by: "Russell King (Oracle)" <[email protected]>
Reviewed-by: Jonathan Cameron <[email protected]>
Reviewed-by: Thomas Gleixner <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>

show more ...

cpu-hotplug: Provide prototypes for arch CPU registration

Provide common prototypes for arch_register_cpu() and
arch_unregister_cpu(). These are called by acpi_processor.c, with weak
versions, so th

cpu-hotplug: Provide prototypes for arch CPU registration

Provide common prototypes for arch_register_cpu() and
arch_unregister_cpu(). These are called by acpi_processor.c, with weak
versions, so the prototype for this is already set. It is generally not
necessary for function prototypes to be conditional on preprocessor macros.

Some architectures (e.g. Loongarch) are missing the prototype for this, and
rather than add it to Loongarch's asm/cpu.h, do the job once for everyone.

Since this covers everyone, remove the now unnecessary prototypes in
asm/cpu.h, and therefore remove the 'static' from one of ia64's
arch_register_cpu() definitions.

[ tglx: Bring back the ia64 part and remove the ACPI prototypes ]

Signed-off-by: Russell King (Oracle) <[email protected]>
Signed-off-by: Thomas Gleixner <[email protected]>
Link: https://lore.kernel.org/r/[email protected]

show more ...

ACPI: processor: Refine messages in acpi_early_processor_control_setup()

The source and meaning of the messages printed by
acpi_early_processor_control_setup() is unclear, so add a pr_fmt()
definiti

ACPI: processor: Refine messages in acpi_early_processor_control_setup()

The source and meaning of the messages printed by
acpi_early_processor_control_setup() is unclear, so add a pr_fmt()
definition to acpi_processor.c and expand the messages to make it
clear that they are about CPUs.

Signed-off-by: Rafael J. Wysocki <[email protected]>
Reviewed-by: Michal Wilczynski <[email protected]>

show more ...

ACPI: processor: Remove acpi_hwp_native_thermal_lvt_osc()

The workaround for buggy skylake BIOSes is now implemented in
acpi_processor_osc() and acpi_hwp_native_thermal_lvt_osc() has no
callers, so

ACPI: processor: Remove acpi_hwp_native_thermal_lvt_osc()

The workaround for buggy skylake BIOSes is now implemented in
acpi_processor_osc() and acpi_hwp_native_thermal_lvt_osc() has no
callers, so drop it.

Suggested-by: Rafael J. Wysocki <[email protected]>
Signed-off-by: Michal Wilczynski <[email protected]>
Reviewed-by: Andy Shevchenko <[email protected]>
[ rjw: Subject and changelog edits ]
Signed-off-by: Rafael J. Wysocki <[email protected]>

show more ...

ACPI: processor: Use _OSC to convey OSPM processor support information

Change acpi_early_processor_osc() to return a value in case of a
failure and make it static.

Also make it run acpi_processor_o

ACPI: processor: Use _OSC to convey OSPM processor support information

Change acpi_early_processor_osc() to return a value in case of a
failure and make it static.

Also make it run acpi_processor_osc() for every processor object or
processor device found in the ACPI Namespace (previously, its only purpose
was to work around platform firmware defects on Skylake systems).

Introduce a new function called acpi_early_processor_control_setup() that
will invoke acpi_early_processor_osc() first in order to convey the OS
processor support information to the platform firmware and if that fails,
it will fall back to using _PDC.

Suggested-by: Rafael J. Wysocki <[email protected]>
Signed-off-by: Michal Wilczynski <[email protected]>
Reviewed-by: Andy Shevchenko <[email protected]>
[ rjw: Subject and changelog edits, change function return value to bool,
add missing 'static', change messages ]
Signed-off-by: Rafael J. Wysocki <[email protected]>

show more ...

ACPI: processor: Introduce acpi_processor_osc()

The processor _OSC method is already used for a workaround introduced
in commit a21211672c9a ("ACPI / processor: Request native thermal
interrupt hand

ACPI: processor: Introduce acpi_processor_osc()

The processor _OSC method is already used for a workaround introduced
in commit a21211672c9a ("ACPI / processor: Request native thermal
interrupt handling via _OSC"), but in accordance with ACPI 6.5 (and
earlier), it should be used for negotiating all of the processor
capabilities instead of _PDC (which has been deprecated since ACPI 3.0
and got removed from ACPI 6.5 entirely).

Create a new callback function called acpi_processor_osc() to be invoked
for every processor object and processor device in the ACPI namespace, in
analogy with the already existing acpi_hwp_native_thermal_lvt_osc().

Make this function implement the workaround mentioned above and convey
all of the OSPM processor support information to the platform firmware
by setting all of the appropriate processor capabilities bits before
evaluating _OSC for the given processor. For this purpose, make it
call arch_acpi_set_proc_cap_bits() and modify the latter to set
ACPI_PROC_CAP_COLLAB_PROC_PERF along with the other processor
capabilities bits.

Suggested-by: Rafael J. Wysocki <[email protected]>
Signed-off-by: Michal Wilczynski <[email protected]>
Reviewed-by: Andy Shevchenko <[email protected]>
[ rjw: Subject and changelog edits, whitespace fixup ]
Signed-off-by: Rafael J. Wysocki <[email protected]>

show more ...

ACPI: processor: Move processor_physically_present() to acpi_processor.c

Since _PDC method is deprecated and a preferred method of communicating
OSPM processor power management capabilities is _OSC,

ACPI: processor: Move processor_physically_present() to acpi_processor.c

Since _PDC method is deprecated and a preferred method of communicating
OSPM processor power management capabilities is _OSC, there is a need to
move function checking whether processor is present as this logic is not
_PDC specific.

Move processor_physically_present() to acpi_processor.c.

No intentional functional impact.

Suggested-by: Rafael J. Wysocki <[email protected]>
Signed-off-by: Michal Wilczynski <[email protected]>
[ rjw: Subject and changelog edits ]
Signed-off-by: Rafael J. Wysocki <[email protected]>

show more ...

ACPI: cpufreq: Use platform devices to load ACPI PPC and PCC drivers

The acpi-cpufreq and pcc-cpufreq drivers are loaded through per-CPU
module aliases. This can result in many unnecessary load requ

ACPI: cpufreq: Use platform devices to load ACPI PPC and PCC drivers

The acpi-cpufreq and pcc-cpufreq drivers are loaded through per-CPU
module aliases. This can result in many unnecessary load requests during
boot if another frequency module, such as intel_pstate, is already
active. For instance, on a typical Intel system, one can observe that
udev makes 2x#CPUs attempts to insert acpi_cpufreq and 1x#CPUs attempts
for pcc_cpufreq. All these tries then fail if another frequency module
is already registered.

In the worst case, without the recent fix in commit 0254127ab977e
("module: Don't wait for GOING modules"), these module loads occupied
all udev workers and had their initialization attempts ran sequentially.
Resolving all these loads then on some larger machines took too long,
prevented other hardware from getting its drivers initialized and
resulted in a failed boot. Discussion over these duplicate module
requests ended up with a conclusion that only one load attempt should be
ideally made.

Both acpi-cpufreq and pcc-cpufreq drivers use platform firmware controls
which are defined by ACPI. It is possible to treat these interfaces as
platform devices.

The patch extends the ACPI parsing logic to check the ACPI namespace if
the PPC or PCC interface is present and creates a virtual platform
device for each if it is available. The acpi-cpufreq and pcc-cpufreq
drivers are then updated to map to these devices.

This allows to try loading acpi-cpufreq and pcc-cpufreq only once during
boot and only if a given interface is available in the firmware.

Signed-off-by: Petr Pavlu <[email protected]>
[ rjw: whitespace and error message log level adjustments, subject edits ]
Signed-off-by: Rafael J. Wysocki <[email protected]>

show more ...

ACPI: processor: Replace deprecated CPU-hotplug functions

The functions cpu_hotplug_begin, cpu_hotplug_done, get_online_cpus() and
put_online_cpus() have been deprecated during the CPU hotplug rewor

ACPI: processor: Replace deprecated CPU-hotplug functions

The functions cpu_hotplug_begin, cpu_hotplug_done, get_online_cpus() and
put_online_cpus() have been deprecated during the CPU hotplug rework. They map
directly to cpus_write_lock(), cpus_write_unlock, cpus_read_lock() and
cpus_read_unlock().

Replace deprecated CPU-hotplug functions with the official version.
The behavior remains unchanged.

Signed-off-by: Sebastian Andrzej Siewior <[email protected]>
Signed-off-by: Rafael J. Wysocki <[email protected]>

show more ...

ACPI: processor: fix some coding style issues

Fix some coding style issues reported by checkpatch.pl, including the
following types:

ERROR: code indent should use tabs where possible
WARNING: Block

ACPI: processor: fix some coding style issues

Fix some coding style issues reported by checkpatch.pl, including the
following types:

ERROR: code indent should use tabs where possible
WARNING: Block comments use a trailing */ on a separate line
WARNING: Missing a blank line after declarations
WARNING: labels should not be indented

Signed-off-by: Xiaofei Tan <[email protected]>
Signed-off-by: Rafael J. Wysocki <[email protected]>

show more ...

ACPI: processor: Get rid of ACPICA message printing

The ACPI_DEBUG_PRINT() and ACPI_EXCEPTION() macros are used for
message printing in the ACPICA code and they should not be used
elsewhere. Specia

ACPI: processor: Get rid of ACPICA message printing

The ACPI_DEBUG_PRINT() and ACPI_EXCEPTION() macros are used for
message printing in the ACPICA code and they should not be used
elsewhere. Special configuration (either kernel command line or
sysfs-based) is needed to see the messages printed by them and
the format of those messages is also special and convoluted.

For this reason, replace all of the ACPI_DEBUG_PRINT() and
ACPI_EXCEPTION() instances in the ACPI processor driver with
corresponding dev_*(), acpi_handle_*() and pr_*() calls depending
on the context in which they appear.

Also drop the ACPI_PROCESSOR_COMPONENT definition that is not going
to be necessary any more.

Signed-off-by: Rafael J. Wysocki <[email protected]>
Reviewed-by: Hanjun Guo <[email protected]>

show more ...

ACPI: processor: remove comment regarding string _UID support

ACPI 6.3 Errata A no longer allows _UID to return a string except for
Itanium (for historical reasons) as stated in section 5.2.12:

"Fr

ACPI: processor: remove comment regarding string _UID support

ACPI 6.3 Errata A no longer allows _UID to return a string except for
Itanium (for historical reasons) as stated in section 5.2.12:

"From ACPI Specification 6.3 onward, all processor objects for all
architectures except Itanium must now use Device() objects with an
_HID of ACPI0007, and use only integer _UID values."

Therefore, the "we don't handle string _UIDs yet" comment, which
implies a missing feature, is redundant, so drop it.

Signed-off-by: Alex Hung <[email protected]>
[ rjw: Subject and changelog edits ]
Signed-off-by: Rafael J. Wysocki <[email protected]>

show more ...