ACPI: HED: Always initialize before evged

When the HED driver is built-in, it initializes after evged because they
both are at the same initcall level, so the initialization ordering
depends on the

ACPI: HED: Always initialize before evged

When the HED driver is built-in, it initializes after evged because they
both are at the same initcall level, so the initialization ordering
depends on the Makefile order. However, this prevents RAS records
coming in between the evged driver initialization and the HED driver
initialization from being handled.

If the number of such RAS records is above the APEI HEST error source
number, the HEST resources may be exhausted, and that may affect
subsequent RAS error reporting.

To fix this issue, change the initcall level of HED to subsys_initcall
and prevent the driver from being built as a module by changing ACPI_HED
in Kconfig from "tristate" to "bool".

Signed-off-by: Xiaofei Tan <[email protected]>
Link: https://patch.msgid.link/[email protected]
[ rjw: Changelog edits ]
Signed-off-by: Rafael J. Wysocki <[email protected]>

show more ...

ACPI: EC: Enable EC support on LoongArch by default

Commit a6021aa24f6417416d933 ("ACPI: EC: make EC support compile-time
conditional") only enable ACPI_EC on X86 by default, but the embedded
contro

ACPI: EC: Enable EC support on LoongArch by default

Commit a6021aa24f6417416d933 ("ACPI: EC: make EC support compile-time
conditional") only enable ACPI_EC on X86 by default, but the embedded
controller is also widely used on LoongArch laptops so we also enable
ACPI_EC for LoongArch.

The laptop driver cannot work without EC, so also update the dependency
of LOONGSON_LAPTOP to let it depend on APCI_EC.

Fixes: a6021aa24f6417416d933 ("ACPI: EC: make EC support compile-time conditional")
Reported-by: Xiaotian Wu <[email protected]>
Tested-by: Binbin Zhou <[email protected]>
Signed-off-by: Huacai Chen <[email protected]>
Link: https://patch.msgid.link/[email protected]
[ rjw: Added Fixes: ]
Signed-off-by: Rafael J. Wysocki <[email protected]>

show more ...

ACPI: EC: make EC support compile-time conditional

The embedded controller code is mainly used on x86 laptops and cannot
work without PC style I/O port access.

Make this a user-visible configuratio

ACPI: EC: make EC support compile-time conditional

The embedded controller code is mainly used on x86 laptops and cannot
work without PC style I/O port access.

Make this a user-visible configuration option that is default enabled
on x86 but otherwise disabled, and that can never be enabled unless
CONFIG_HAS_IOPORT is also available.

The empty stubs in internal.h help ignore the EC code in configurations
that don't support it. In order to see those stubs, the sbshc code also
has to include this header and drop duplicate declarations.

All the direct callers of ec_read/ec_write already had an x86
dependency and now also need to depend on APCI_EC.

Signed-off-by: Arnd Bergmann <[email protected]>
Acked-by: Guenter Roeck <[email protected]>
Acked-by: Hans de Goede <[email protected]>
Link: https://patch.msgid.link/[email protected]
[ rjw: Subject edits ]
Signed-off-by: Rafael J. Wysocki <[email protected]>

show more ...

LoongArch: Enable ACPI BGRT handling

Add ACPI BGRT support on LoongArch so it can display image provied by
acpi table at boot stage and switch to graphical UI smoothly.

Signed-off-by: Bibo Mao <mao

LoongArch: Enable ACPI BGRT handling

Add ACPI BGRT support on LoongArch so it can display image provied by
acpi table at boot stage and switch to graphical UI smoothly.

Signed-off-by: Bibo Mao <[email protected]>
Signed-off-by: Huacai Chen <[email protected]>

show more ...

ACPI: NHLT: Introduce API for the table

The table is composed of a range of endpoints with each describing
audio formats they support. Most of the operations involve iterating
over elements of the t

ACPI: NHLT: Introduce API for the table

The table is composed of a range of endpoints with each describing
audio formats they support. Most of the operations involve iterating
over elements of the table and filtering them. Simplify the process by
implementing range of getters.

While the acpi_nhlt_endpoint_mic_count() stands out a bit, it is a
critical component for any AudioDSP driver to know how many digital
microphones it is dealing with.

Signed-off-by: Cezary Rojewski <[email protected]>
Signed-off-by: Rafael J. Wysocki <[email protected]>

show more ...

ACPI: Enable ACPI_PROCESSOR for RISC-V

The ACPI processor driver is not currently enabled for RISC-V.
This is required to enable CPU related functionalities like
LPI and CPPC. Hence, enable ACPI_PRO

ACPI: Enable ACPI_PROCESSOR for RISC-V

The ACPI processor driver is not currently enabled for RISC-V.
This is required to enable CPU related functionalities like
LPI and CPPC. Hence, enable ACPI_PROCESSOR for RISC-V.

Signed-off-by: Sunil V L <[email protected]>
Reviewed-by: Andrew Jones <[email protected]>
Acked-by: Rafael J. Wysocki <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Palmer Dabbelt <[email protected]>

show more ...

ACPI: Drop the custom_method debugfs interface

The ACPI custom_method debugfs interface is security-sensitive and
concurrent access to it is broken [1].

Moreover, the recipe for preparing a customi

ACPI: Drop the custom_method debugfs interface

The ACPI custom_method debugfs interface is security-sensitive and
concurrent access to it is broken [1].

Moreover, the recipe for preparing a customized version of a given
control method has changed at one point due to ACPICA changes, which
has not been reflected in its documentation, so whoever used it before
has had to adapt and it had gone unnoticed for a long time.

This interface was a bad idea to start with and its implementation is
fragile at the design level. It's been always conceptually questionable,
problematic from the security standpoint and implemented poorly.

Patches fixing its most apparent functional issues (for example, [2]) don't
actually address much of the above.

Granted, at the time it was introduced, there was no alternative, but
there is the AML debugger in the kernel now and there is the configfs
interface allowing custom ACPI tables to be loaded. The former can be
used for extensive AML debugging and the latter can be use for testing
new AML. [3]

Accordingly, drop custom_method along with its (outdated anyway)
documentation.

Link: https://lore.kernel.org/linux-acpi/[email protected]/ # [1]
Link: https://lore.kernel.org/linux-acpi/[email protected]/ [2]
Link: https://stackoverflow.com/questions/62849113/how-to-unload-an-overlay-loaded-using-acpi-config-sysfs # [3]
Reported-by: Hang Zhang <[email protected]>
Signed-off-by: Rafael J. Wysocki <[email protected]>
Reviewed-by: Zhang Rui <[email protected]>
Reviewed-by: Kees Cook <[email protected]>

show more ...

treewide: replace or remove redundant def_bool in Kconfig files

'def_bool X' is a shorthand for 'bool' plus 'default X'.

'def_bool' is redundant where 'bool' is already present, so 'def_bool X'
can

treewide: replace or remove redundant def_bool in Kconfig files

'def_bool X' is a shorthand for 'bool' plus 'default X'.

'def_bool' is redundant where 'bool' is already present, so 'def_bool X'
can be replaced with 'default X', or removed if X is 'n'.

Signed-off-by: Masahiro Yamada <[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 ...

thermal: ACPI: Move the ACPI thermal library to drivers/acpi/

The ACPI thermal library contains functions that can be used to
retrieve trip point temperature values through the platform firmware
for

thermal: ACPI: Move the ACPI thermal library to drivers/acpi/

The ACPI thermal library contains functions that can be used to
retrieve trip point temperature values through the platform firmware
for various types of trip points. Each of these functions basically
evaluates a specific ACPI object, checks if the value produced by it
is reasonable and returns it (or THERMAL_TEMP_INVALID if anything
fails).

It made sense to hold it in drivers/thermal/ so long as it was only used
by the code in that directory, but since it is also going to be used by
the ACPI thermal driver located in drivers/acpi/, move it to the latter
in order to keep the code related to evaluating ACPI objects defined in
the specification proper together.

No intentional functional impact.

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

show more ...

acpi: Move common tables helper functions to common lib

Some of the routines in ACPI driver/acpi/tables.c can be shared with
parsing CDAT. CDAT is a device-provided data structure that is formatted

acpi: Move common tables helper functions to common lib

Some of the routines in ACPI driver/acpi/tables.c can be shared with
parsing CDAT. CDAT is a device-provided data structure that is formatted
similar to a platform provided ACPI table. CDAT is used by CXL and can
exist on platforms that do not use ACPI. Split out the common routine
from ACPI to accommodate platforms that do not support ACPI and move that
to /lib. The common routines can be built outside of ACPI if
FIRMWARE_TABLES is selected.

Link: https://lore.kernel.org/linux-cxl/CAJZ5v0jipbtTNnsA0-o5ozOk8ZgWnOg34m34a9pPenTyRLj=6A@mail.gmail.com/
Suggested-by: "Rafael J. Wysocki" <[email protected]>
Reviewed-by: Hanjun Guo <[email protected]>
Reviewed-by: Jonathan Cameron <[email protected]>
Signed-off-by: Dave Jiang <[email protected]>
Acked-by: "Rafael J. Wysocki" <[email protected]>
Link: https://lore.kernel.org/r/169713683430.2205276.17899451119920103445.stgit@djiang5-mobl3
Signed-off-by: Dan Williams <[email protected]>

show more ...

arch: Remove Itanium (IA-64) architecture

The Itanium architecture is obsolete, and an informal survey [0] reveals
that any residual use of Itanium hardware in production is mostly HP-UX
or OpenVMS

arch: Remove Itanium (IA-64) architecture

The Itanium architecture is obsolete, and an informal survey [0] reveals
that any residual use of Itanium hardware in production is mostly HP-UX
or OpenVMS based. The use of Linux on Itanium appears to be limited to
enthusiasts that occasionally boot a fresh Linux kernel to see whether
things are still working as intended, and perhaps to churn out some
distro packages that are rarely used in practice.

None of the original companies behind Itanium still produce or support
any hardware or software for the architecture, and it is listed as
'Orphaned' in the MAINTAINERS file, as apparently, none of the engineers
that contributed on behalf of those companies (nor anyone else, for that
matter) have been willing to support or maintain the architecture
upstream or even be responsible for applying the odd fix. The Intel
firmware team removed all IA-64 support from the Tianocore/EDK2
reference implementation of EFI in 2018. (Itanium is the original
architecture for which EFI was developed, and the way Linux supports it
deviates significantly from other architectures.) Some distros, such as
Debian and Gentoo, still maintain [unofficial] ia64 ports, but many have
dropped support years ago.

While the argument is being made [1] that there is a 'for the common
good' angle to being able to build and run existing projects such as the
Grid Community Toolkit [2] on Itanium for interoperability testing, the
fact remains that none of those projects are known to be deployed on
Linux/ia64, and very few people actually have access to such a system in
the first place. Even if there were ways imaginable in which Linux/ia64
could be put to good use today, what matters is whether anyone is
actually doing that, and this does not appear to be the case.

There are no emulators widely available, and so boot testing Itanium is
generally infeasible for ordinary contributors. GCC still supports IA-64
but its compile farm [3] no longer has any IA-64 machines. GLIBC would
like to get rid of IA-64 [4] too because it would permit some overdue
code cleanups. In summary, the benefits to the ecosystem of having IA-64
be part of it are mostly theoretical, whereas the maintenance overhead
of keeping it supported is real.

So let's rip off the band aid, and remove the IA-64 arch code entirely.
This follows the timeline proposed by the Debian/ia64 maintainer [5],
which removes support in a controlled manner, leaving IA-64 in a known
good state in the most recent LTS release. Other projects will follow
once the kernel support is removed.

[0] https://lore.kernel.org/all/CAMj1kXFCMh_578jniKpUtx_j8ByHnt=s7S+yQ+vGbKt9ud7+kQ@mail.gmail.com/
[1] https://lore.kernel.org/all/[email protected]/
[2] https://gridcf.org/gct-docs/latest/index.html
[3] https://cfarm.tetaneutral.net/machines/list/
[4] https://lore.kernel.org/all/[email protected]/
[5] https://lore.kernel.org/all/ff58a3e76e5102c94bb5946d99187b358def688a.camel@physik.fu-berlin.de/

Acked-by: Tony Luck <[email protected]>
Signed-off-by: Ard Biesheuvel <[email protected]>

show more ...

acpi/prmt: Use EFI runtime sandbox to invoke PRM handlers

Instead of bypassing the kernel's adaptation layer for performing EFI
runtime calls, wire up ACPI PRM handling into it. This means these cal

acpi/prmt: Use EFI runtime sandbox to invoke PRM handlers

Instead of bypassing the kernel's adaptation layer for performing EFI
runtime calls, wire up ACPI PRM handling into it. This means these calls
can no longer occur concurrently with EFI runtime calls, and will be
made from the EFI runtime workqueue. It also means any page faults
occurring during PRM handling will be identified correctly as
originating in firmware code.

Acked-by: Rafael J. Wysocki <[email protected]>
Signed-off-by: Ard Biesheuvel <[email protected]>

show more ...

LoongArch: Add SMT (Simultaneous Multi-Threading) support

Loongson-3A6000 has SMT (Simultaneous Multi-Threading) support, each
physical core has two logical cores (threads). This patch add SMT probe

LoongArch: Add SMT (Simultaneous Multi-Threading) support

Loongson-3A6000 has SMT (Simultaneous Multi-Threading) support, each
physical core has two logical cores (threads). This patch add SMT probe
and scheduler support via ACPI PPTT.

If SCHED_SMT enabled, Loongson-3A6000 is treated as 4 cores, 8 threads;
If SCHED_SMT disabled, Loongson-3A6000 is treated as 8 cores, 8 threads.

Remove smp_num_siblings to support HMP (Heterogeneous Multi-Processing).

Signed-off-by: Liupu Wang <[email protected]>
Signed-off-by: Huacai Chen <[email protected]>

show more ...

ACPI: Implement a generic FFH Opregion handler

This registers the FFH OpRegion handler before ACPI tables are
loaded. The platform support for the same is checked via Platform-Wide
OSPM Capabilities

ACPI: Implement a generic FFH Opregion handler

This registers the FFH OpRegion handler before ACPI tables are
loaded. The platform support for the same is checked via Platform-Wide
OSPM Capabilities(OSC) before registering the OpRegion handler.

It relies on the special context data passed to offset and the length.
However the interpretation of the values is platform/architecture
specific. This generic handler just passed all the information to
the platform/architecture specific callback. It also implements the
default callbacks which return as not supported.

Signed-off-by: Sudeep Holla <[email protected]>
Signed-off-by: Rafael J. Wysocki <[email protected]>

show more ...

ACPI: Enable FPDT on arm64

FPDT provides some boot timing records useful for analyzing
parts of the UEFI boot stack. Given the existing code works
on arm64, and allows reading the values without uti

ACPI: Enable FPDT on arm64

FPDT provides some boot timing records useful for analyzing
parts of the UEFI boot stack. Given the existing code works
on arm64, and allows reading the values without utilizing
/dev/mem it seems like a good idea to turn it on.

Signed-off-by: Jeremy Linton <[email protected]>
Acked-by: Sudeep Holla <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Will Deacon <[email protected]>

show more ...

ACPI: Kconfig: Drop link to https://01.org/linux-acpi

Because the https://01.org/linux-acpi web site has become permanently
inaccessible, drop the remaining link to it from the ACPI Kconfig.

Signed

ACPI: Kconfig: Drop link to https://01.org/linux-acpi

Because the https://01.org/linux-acpi web site has become permanently
inaccessible, drop the remaining link to it from the ACPI Kconfig.

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

show more ...

ACPI: docs: Drop useless DSDT override documentation

Because https://01.org/linux-acpi web site has become permanently
inaccessible, the "Overriding DSDT" document in the kernel tree
pointing to it

ACPI: docs: Drop useless DSDT override documentation

Because https://01.org/linux-acpi web site has become permanently
inaccessible, the "Overriding DSDT" document in the kernel tree
pointing to it as the main source of information is useless (and
the config option name mentioned by it is incorrect), so drop it
and drop the pointer to it from the ACPI Kconfig.

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

show more ...

ACPI: video: Add Nvidia WMI EC brightness control detection (v3)

On some new laptop designs a new Nvidia specific WMI interface is present
which gives info about panel brightness control and may all

ACPI: video: Add Nvidia WMI EC brightness control detection (v3)

On some new laptop designs a new Nvidia specific WMI interface is present
which gives info about panel brightness control and may allow controlling
the brightness through this interface when the embedded controller is used
for brightness control.

When this WMI interface is present and indicates that the EC is used,
then this interface should be used for brightness control.

Changes in v2:
- Use the new shared nvidia-wmi-ec-backlight.h header for the
WMI firmware API definitions
- ACPI_VIDEO can now be enabled on non X86 too,
adjust the Kconfig changes to match this.

Changes in v3:
- Use WMI_BRIGHTNESS_GUID define

Acked-by: Rafael J. Wysocki <[email protected]>
Reviewed-by: Daniel Dadap <[email protected]>
Signed-off-by: Hans de Goede <[email protected]>

show more ...

ACPI: Move PRM config option under the main ACPI config

Currently PRM(Platform Runtime Mechanism) config option is listed along
with the main ACPI (Advanced Configuration and Power Interface) option

ACPI: Move PRM config option under the main ACPI config

Currently PRM(Platform Runtime Mechanism) config option is listed along
with the main ACPI (Advanced Configuration and Power Interface) option
at the same level. On ARM64 platforms unlike x86, ACPI option is listed
at the topmost level of configuration menu. It is rather very confusing
to see PRM option also listed along with ACPI in the topmost level.

Move the same under ACPI config option. No functional change, just changes
the level of visibility of this option under the configuration menu.

Signed-off-by: Sudeep Holla <[email protected]>
Acked-by: Rafael J. Wysocki <[email protected]>
Signed-off-by: Ard Biesheuvel <[email protected]>

show more ...

ACPI: Enable Platform Runtime Mechanism(PRM) support on ARM64

There is interest to make use of PRM(Platform Runtime Mechanism) even on
ARM64 ACPI platforms. Allow PRM to be enabled on ARM64 platform

ACPI: Enable Platform Runtime Mechanism(PRM) support on ARM64

There is interest to make use of PRM(Platform Runtime Mechanism) even on
ARM64 ACPI platforms. Allow PRM to be enabled on ARM64 platforms. It will
be enabled by default as on x86_64.

Signed-off-by: Sudeep Holla <[email protected]>
Acked-by: Rafael J. Wysocki <[email protected]>
Signed-off-by: Ard Biesheuvel <[email protected]>

show more ...

ACPI: processor: Split out thermal initialization from ACPI PSS

Commit 239708a3af44 ("ACPI: Split out ACPI PSS from ACPI Processor
driver"), moves processor thermal registration to acpi_pss_perf_ini

ACPI: processor: Split out thermal initialization from ACPI PSS

Commit 239708a3af44 ("ACPI: Split out ACPI PSS from ACPI Processor
driver"), moves processor thermal registration to acpi_pss_perf_init(),
which doesn't get executed if ACPI_CPU_FREQ_PSS is not enabled.

As ARM64 supports P-states using CPPC, it should be possible to also
support processor passive cooling even if PSS is not enabled. Split
out the processor thermal cooling register from ACPI PSS to support
this, and move it into a separate function in processor_thermal.c.

Signed-off-by: Riwen Lu <[email protected]>
Reviewed-by: Punit Agrawal <[email protected]>
[ rjw: Subject edits ]
Signed-off-by: Rafael J. Wysocki <[email protected]>

show more ...

ACPI: video: Drop X86 dependency from Kconfig

The ACPI video device is also present in ARM64 laptops, so drop the
Kconfig dependency on X86 for ACPI_VIDEO.

Signed-off-by: Riwen Lu <luriwen@kylinos.

ACPI: video: Drop X86 dependency from Kconfig

The ACPI video device is also present in ARM64 laptops, so drop the
Kconfig dependency on X86 for ACPI_VIDEO.

Signed-off-by: Riwen Lu <[email protected]>
[ rjw: Subject rewrite, changelog edits ]
Signed-off-by: Rafael J. Wysocki <[email protected]>

show more ...

ACPI: clean up double words in two comments

Remove the second 'on' and 'those'.

Signed-off-by: Tom Rix <[email protected]>
[ rjw: Subject adjustments ]
Signed-off-by: Rafael J. Wysocki <rafael.j.wyso

ACPI: clean up double words in two comments

Remove the second 'on' and 'those'.

Signed-off-by: Tom Rix <[email protected]>
[ rjw: Subject adjustments ]
Signed-off-by: Rafael J. Wysocki <[email protected]>

show more ...

ACPI: require CRC32 to build

ACPI core now requires crc32() but the kernel build can fail when
CRC32 is not set/enabled, so select it in the ACPI Kconfig entry.

Fixes this build error:

ia64-linux-

ACPI: require CRC32 to build

ACPI core now requires crc32() but the kernel build can fail when
CRC32 is not set/enabled, so select it in the ACPI Kconfig entry.

Fixes this build error:

ia64-linux-ld: drivers/acpi/scan.o: in function `acpi_store_pld_crc':
include/acpi/platform/aclinuxex.h:62: undefined reference to `crc32_le'

Fixes: 882c982dada4 ("acpi: Store CRC-32 hash of the _PLD in struct acpi_device")
Signed-off-by: Randy Dunlap <[email protected]>
Reported-by: Guenter Roeck <[email protected]>
Reviewed-by: Guenter Roeck <[email protected]>
Tested-by: Guenter Roeck <[email protected]>
Signed-off-by: Rafael J. Wysocki <[email protected]>

show more ...