linux-stable.git/drivers/acpi/acpi_processor.c, branch linux-5.4.y

ACPI: processor: fix acpi_object initialization

2025-08-28T14:21:25+00:00

[ Upstream commit 13edf7539211d8f7d0068ce3ed143005f1da3547 ]

Initialization of the local acpi_object in acpi_processor_get_info()
only sets the first 4 bytes to zero and is thus incomplete. This is
indicated by messages like:
	acpi ACPI0007:be: Invalid PBLK length [166288104]

Fix this by initializing all 16 bytes of the processor member of that
union.

Signed-off-by: Sebastian Ott 
Link: https://patch.msgid.link/20250703124215.12522-1-sebott@redhat.com
Signed-off-by: Rafael J. Wysocki 
Signed-off-by: Sasha Levin

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

2024-09-12T09:03:56+00:00

[ Upstream commit 47ec9b417ed9b6b8ec2a941cd84d9de62adc358a ]

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 
Reviewed-by: Gavin Shan 
Signed-off-by: Jonathan Cameron 
Link: https://lore.kernel.org/r/20240529133446.28446-6-Jonathan.Cameron@huawei.com
Signed-off-by: Catalin Marinas 
Signed-off-by: Sasha Levin

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

2024-09-12T09:03:56+00:00

[ Upstream commit fadf231f0a06a6748a7fc4a2c29ac9ef7bca6bfd ]

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 
Acked-by: Rafael J. Wysocki 
Reviewed-by: Gavin Shan 
Signed-off-by: Jonathan Cameron 
Link: https://lore.kernel.org/r/20240529133446.28446-5-Jonathan.Cameron@huawei.com
Signed-off-by: Catalin Marinas 
Signed-off-by: Sasha Levin

ACPI / processor: don't print errors for processorIDs == 0xff

2019-08-09T08:48:34+00:00

Some platforms define their processors in this manner:
    Device (SCK0)
    {
	Name (_HID, "ACPI0004" /* Module Device */)  // _HID: Hardware ID
	Name (_UID, "CPUSCK0")  // _UID: Unique ID
	Processor (CP00, 0x00, 0x00000410, 0x06){}
	Processor (CP01, 0x02, 0x00000410, 0x06){}
	Processor (CP02, 0x04, 0x00000410, 0x06){}
	Processor (CP03, 0x06, 0x00000410, 0x06){}
	Processor (CP04, 0x01, 0x00000410, 0x06){}
	Processor (CP05, 0x03, 0x00000410, 0x06){}
	Processor (CP06, 0x05, 0x00000410, 0x06){}
	Processor (CP07, 0x07, 0x00000410, 0x06){}
	Processor (CP08, 0xFF, 0x00000410, 0x06){}
	Processor (CP09, 0xFF, 0x00000410, 0x06){}
	Processor (CP0A, 0xFF, 0x00000410, 0x06){}
	Processor (CP0B, 0xFF, 0x00000410, 0x06){}
...

The processors marked as 0xff are invalid, there are only 8 of them in
this case.

So do not print an error on ids == 0xff, just print an info message.
Actually, we could return ENODEV even on the first CPU with ID 0xff, but
ACPI spec does not forbid the 0xff value to be a processor ID. Given
0xff could be a correct one, we would break working systems if we
returned ENODEV.

Signed-off-by: Jiri Slaby 
Signed-off-by: Rafael J. Wysocki

treewide: Replace GPLv2 boilerplate/reference with SPDX - rule 500

2019-06-19T15:09:55+00:00

Based on 2 normalized pattern(s):

  this program is free software you can redistribute it and or modify
  it under the terms of the gnu general public license version 2 as
  published by the free software foundation

  this program is free software you can redistribute it and or modify
  it under the terms of the gnu general public license version 2 as
  published by the free software foundation #

extracted by the scancode license scanner the SPDX license identifier

  GPL-2.0-only

has been chosen to replace the boilerplate/reference in 4122 file(s).

Signed-off-by: Thomas Gleixner 
Reviewed-by: Enrico Weigelt 
Reviewed-by: Kate Stewart 
Reviewed-by: Allison Randal 
Cc: linux-spdx@vger.kernel.org
Link: https://lkml.kernel.org/r/20190604081206.933168790@linutronix.de
Signed-off-by: Greg Kroah-Hartman

ACPI / processor: Fix the return value of acpi_processor_ids_walk()

2018-10-04T06:58:32+00:00

ACPI driver should make sure all the processor IDs in their ACPI Namespace
are unique. the driver performs a depth-first walk of the namespace tree
and calls the acpi_processor_ids_walk() to check the duplicate IDs.

But, the acpi_processor_ids_walk() mistakes the return value. If a
processor is checked, it returns true which causes the walk break
immediately, and other processors will never be checked.

Repace the value with AE_OK which is the standard acpi_status value.
And don't abort the namespace walk even on error.

Fixes: 8c8cb30f49b8 (acpi/processor: Implement DEVICE operator for processor enumeration)
Signed-off-by: Dou Liyang 
Signed-off-by: Rafael J. Wysocki

ACPI: Mark expected switch fall-throughs

2017-11-08T23:55:16+00:00

In preparation to enabling -Wimplicit-fallthrough, mark switch cases
where we are expecting to fall through.

Signed-off-by: Gustavo A. R. Silva 
Signed-off-by: Rafael J. Wysocki

ACPI / processor: make function acpi_processor_check_duplicates() static

2017-08-24T01:25:47+00:00

The function acpi_processor_check_duplicates() is local to the source
and does not need to be in global scope, so make it static.

Cleans up sparse warnings:
symbol 'acpi_processor_check_duplicates' was not declared. Should it
be static?

Signed-off-by: Colin Ian King 
Signed-off-by: Rafael J. Wysocki

ACPI / Processor: Drop setup_max_cpus check from acpi_processor_add()

2017-04-18T14:50:24+00:00

When maxcpus=X kernel argument is used, we parse the ACPI tables only
for the first X cpus. The per-cpu ACPI data include the _PSD tables
which gives information about related cpus.

cppc_cpufreq and acpi-cpufreq parses the table once during init to
deduce the related cpus. If a user brings a new cpu online after boot
the related cpu data becomes incorrect.

acpi_get_psd_map() in acpi_cppc.c returns error if it fails to find
the parsed ACPI data for possible CPU resulting in cppc_cpufreq
initialization failure.

With this change we will probe all possible CPUs prior to cpufreq
initialization, but will bring only setup_max_cpus online. nr_cpus
kernel parameter can be used to restict even parsing per-cpu ACPI
tables.

Signed-off-by: Prashanth Prakash 
[ rjw: Subject ]
Signed-off-by: Rafael J. Wysocki

acpi/processor: Check for duplicate processor ids at hotplug time

2017-03-11T13:41:20+00:00

The check for duplicate processor ids happens at boot time based on the
ACPI table contents, but the final sanity checks for a processor happen
at hotplug time.

At hotplug time, where the physical information is available, which might
differ from the ACPI table information, a check for duplicate processor
ids is missing.

Add it to the hotplug checks and rename the function so it better
reflects its purpose.

Signed-off-by: Dou Liyang 
Tested-by: Xiaolong Ye 
Cc: rjw@rjwysocki.net
Cc: linux-acpi@vger.kernel.org
Cc: guzheng1@huawei.com
Cc: izumi.taku@jp.fujitsu.com
Cc: lenb@kernel.org
Link: http://lkml.kernel.org/r/1488528147-2279-6-git-send-email-douly.fnst@cn.fujitsu.com
Signed-off-by: Thomas Gleixner