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

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

2024-09-12T09:13:08+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:13:08+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 
Stable-dep-of: 47ec9b417ed9 ("ACPI: processor: Fix memory leaks in error paths of processor_add()")
Signed-off-by: Sasha Levin

Merge branches 'acpi-x86', 'acpi-video', 'acpi-apei' and 'acpi-misc'

2024-03-11T13:42:30+00:00

Merge x86-specific ACPI changes, an ACPI backlight driver change, ACPI
APEI change and miscellaneous ACPI-related changes for 6.9-rc1:

 - Add DELL0501 handling to acpi_quirk_skip_serdev_enumeration() and
   make that function generic (Hans de Goede).

 - Make the ACPI backlight code handle fetching EDID that is longer than
   256 bytes (Mario Limonciello).

 - Skip initialization of GHES_ASSIST structures for Machine Check
   Architecture in APEI (Avadhut Naik).

 - Convert several plaform drivers in the ACPI subsystem to using a
   remove callback that returns void (Uwe Kleine-König).

 - Drop the long-deprecated custom_method debugfs interface that is
   problematic from the security standpoint (Rafael Wysocki).

 - Use %pe in a couple of places in the ACPI code for easier error
   decoding (Onkarnath).

* acpi-x86:
  ACPI: x86: Add DELL0501 handling to acpi_quirk_skip_serdev_enumeration()
  ACPI: x86: Move acpi_quirk_skip_serdev_enumeration() out of CONFIG_X86_ANDROID_TABLETS

* acpi-video:
  ACPI: video: Handle fetching EDID that is longer than 256 bytes

* acpi-apei:
  ACPI: APEI: Skip initialization of GHES_ASSIST structures for Machine Check Architecture
  ACPI: APEI: GHES: Convert to platform remove callback returning void

* acpi-misc:
  ACPI: pfr_update: Convert to platform remove callback returning void
  ACPI: pfr_telemetry: Convert to platform remove callback returning void
  ACPI: fan: Convert to platform remove callback returning void
  ACPI: GED: Convert to platform remove callback returning void
  ACPI: DPTF: Convert to platform remove callback returning void
  ACPI: AGDI: Convert to platform remove callback returning void
  ACPI: TAD: Convert to platform remove callback returning void
  ACPI: Drop the custom_method debugfs interface
  ACPI: use %pe for better readability of errors while printing

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

2024-02-27T16:54:59+00:00

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 
Reviewed-by: Jonathan Cameron

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

2024-02-16T18:31:12+00:00

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 
Signed-off-by: Maninder Singh 
Signed-off-by: Onkarnath 
Reviewed-by: Stanislaw Gruszka 
Signed-off-by: Rafael J. Wysocki

ACPI: Move ACPI_HOTPLUG_CPU to be disabled on arm64 and riscv

2023-12-06T03:41:48+00:00

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 
Reviewed-by: Shaoqin Huang 
Reviewed-by: Gavin Shan 
Signed-off-by: "Russell King (Oracle)" 
Reviewed-by: Jonathan Cameron 
Reviewed-by: Thomas Gleixner 
Link: https://lore.kernel.org/r/E1r5R31-00Csyt-Jq@rmk-PC.armlinux.org.uk
Signed-off-by: Greg Kroah-Hartman

cpu-hotplug: Provide prototypes for arch CPU registration

2023-10-11T12:27:37+00:00

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) 
Signed-off-by: Thomas Gleixner 
Link: https://lore.kernel.org/r/E1qkoRr-0088Q8-Da@rmk-PC.armlinux.org.uk

ACPI: processor: Refine messages in acpi_early_processor_control_setup()

2023-07-20T19:05:00+00:00

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 
Reviewed-by: Michal Wilczynski

ACPI: processor: Remove acpi_hwp_native_thermal_lvt_osc()

2023-07-17T12:47:42+00:00

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 
Signed-off-by: Michal Wilczynski 
Reviewed-by: Andy Shevchenko 
[ rjw: Subject and changelog edits ]
Signed-off-by: Rafael J. Wysocki

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

2023-07-17T12:47:18+00:00

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