History log of /linux/drivers/acpi/Kconfig (Results 1 – 25 of 403)
Revision Date Author Comments
# 1b7cbe34 01-Apr-2026 Xi Ruoyao <xry111@xry111.site>

ACPI: tables: Enable FPDT on LoongArch

FPDT provides system- and application-readable performance statistics,
useful for profiling and analyzing boot-time performance. FPDT table
support is now avai

ACPI: tables: Enable FPDT on LoongArch

FPDT provides system- and application-readable performance statistics,
useful for profiling and analyzing boot-time performance. FPDT table
support is now available as a pending patch at the EDK II upstream [1]
and has been tested on real hardware such as Loongson XA61200_V1.1 and
XB612B0_V1.2 with patched firmware.

We have also cross checked systemd-analyze(1) against a stop watch and
the `dp' command in EFI Shell to see that the timing information are
correct.

Now that the functionality of FPDT is verified on LoongArch hardware,
list LOONGARCH as a possible dependency, allowing it to be enabled.

Link: https://github.com/tianocore/edk2/pull/12378 [1]
Signed-off-by: Xi Ruoyao <xry111@xry111.site>
[ rjw: Subject tweak ]
Link: https://patch.msgid.link/20260401135311.1737958-2-xry111@xry111.site
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>

show more ...


# 6ab3532b 09-Mar-2026 Rafael J. Wysocki <rafael.j.wysocki@intel.com>

ACPI: video: Switch over to auxiliary bus type

Commit 02c057ddefef ("ACPI: video: Convert the driver to a platform one")
switched over the ACPI video bus driver from an ACPI driver to a platform
dri

ACPI: video: Switch over to auxiliary bus type

Commit 02c057ddefef ("ACPI: video: Convert the driver to a platform one")
switched over the ACPI video bus driver from an ACPI driver to a platform
driver, but that change introduced an unwanted and unexpected side effect.
Namely, on some systems, the ACPI device object of the ACPI video bus
device is an ACPI companion of multiple platform devices and, after
adding video_device_ids[] as an acpi_match_table to the acpi_video_bus
platform driver, all of those devices started to match that driver and
its probe callback is invoked for all of them (it fails, but it leaves
a confusing message in the log). Moreover, the MODULE_DEVICE_TABLE()
of the ACPI video driver module matches all of the devices sharing the
ACPI companion with the ACPI video bus device.

To address this, make the core ACPI device enumeration code create an
auxiliary device for the ACPI video bus device object instead of a
platform device and switch over the ACPI video bus driver (once more)
to an auxiliary driver.

Auxiliary driver generally is a better match for ACPI video bus than
platform driver, among other things because the ACPI video bus device
does not require any resources to be allocated for it during
enumeration. It also allows the ACPI video bus driver to stop abusing
device matching based on ACPI device IDs and it allows a special case
to be dropped from acpi_create_platform_device() because that function
need not worry about the ACPI video bus device any more.

Fixes: 02c057ddefef ("ACPI: video: Convert the driver to a platform one")
Reported-by: Pratap Nirujogi <pratap.nirujogi@amd.com>
Closes: https://lore.kernel.org/linux-acpi/007e3390-6b2b-457e-83c7-c794c5952018@amd.com/
Tested-by: Pratap Nirujogi <pratap.nirujogi@amd.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Mario Limonciello (AMD) <superm1@kernel.org>
[ rjw: Added AUXILIARY_BUS selection to CONFIG_ACPI to fix build issue ]
[ rjw: Fixed error path in acpi_create_video_bus_device() ]
Link: https://patch.msgid.link/5986516.DvuYhMxLoT@rafael.j.wysocki
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>

show more ...


# 95350eff 14-Jan-2026 Fabio M. De Francesco <fabio.m.de.francesco@linux.intel.com>

ACPI: extlog: Trace CPER CXL Protocol Error Section

When Firmware First is enabled, BIOS handles errors first and then it
makes them available to the kernel via the Common Platform Error Record
(CPE

ACPI: extlog: Trace CPER CXL Protocol Error Section

When Firmware First is enabled, BIOS handles errors first and then it
makes them available to the kernel via the Common Platform Error Record
(CPER) sections (UEFI 2.11 Appendix N.2.13). Linux parses the CPER
sections via one of two similar paths, either ELOG or GHES. The errors
managed by ELOG are signaled to the BIOS by the I/O Machine Check
Architecture (I/O MCA).

Currently, ELOG and GHES show some inconsistencies in how they report to
userspace via trace events.

Therefore, make the two mentioned paths act similarly by tracing the CPER
CXL Protocol Error Section.

Reviewed-by: Dave Jiang <dave.jiang@intel.com>
Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com>
Reviewed-by: Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com>
Signed-off-by: Fabio M. De Francesco <fabio.m.de.francesco@linux.intel.com>
Link: https://patch.msgid.link/20260114101543.85926-6-fabio.m.de.francesco@linux.intel.com
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>

show more ...


# 86bcf7be 04-Oct-2025 Linus Torvalds <torvalds@linux-foundation.org>

Merge tag 'riscv-for-linus-6.18-mw2' of git://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux

Pull more RISC-V updates from Paul Walmsley:

- Support for the RISC-V-standardized RPMI interface.

Merge tag 'riscv-for-linus-6.18-mw2' of git://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux

Pull more RISC-V updates from Paul Walmsley:

- Support for the RISC-V-standardized RPMI interface.

RPMI is a platform management communication mechanism between OSes
running on application processors, and a remote platform management
processor. Similar to ARM SCMI, TI SCI, etc. This includes irqchip,
mailbox, and clk changes.

- Support for the RISC-V-standardized MPXY SBI extension.

MPXY is a RISC-V-specific standard implementing a shared memory
mailbox between S-mode operating systems (e.g., Linux) and M-mode
firmware (e.g., OpenSBI). It is part of this PR since one of its use
cases is to enable M-mode firmware to act as a single RPMI client for
all RPMI activity on a core (including S-mode RPMI activity).
Includes a mailbox driver.

- Some ACPI-related updates to enable the use of RPMI and MPXY.

- The addition of Linux-wide memcpy_{from,to}_le32() static inline
functions, for RPMI use.

- An ACPI Kconfig change to enable boot logos on any ACPI-using
architecture (including RISC-V)

- A RISC-V defconfig change to add GPIO keyboard and event device
support, for front panel shutdown or reboot buttons

* tag 'riscv-for-linus-6.18-mw2' of git://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux: (26 commits)
clk: COMMON_CLK_RPMI should depend on RISCV
ACPI: support BGRT table on RISC-V
MAINTAINERS: Add entry for RISC-V RPMI and MPXY drivers
RISC-V: Enable GPIO keyboard and event device in RV64 defconfig
irqchip/riscv-rpmi-sysmsi: Add ACPI support
mailbox/riscv-sbi-mpxy: Add ACPI support
irqchip/irq-riscv-imsic-early: Export imsic_acpi_get_fwnode()
ACPI: RISC-V: Add RPMI System MSI to GSI mapping
ACPI: RISC-V: Add support to update gsi range
ACPI: RISC-V: Create interrupt controller list in sorted order
ACPI: scan: Update honor list for RPMI System MSI
ACPI: Add support for nargs_prop in acpi_fwnode_get_reference_args()
ACPI: property: Refactor acpi_fwnode_get_reference_args() to support nargs_prop
irqchip: Add driver for the RPMI system MSI service group
dt-bindings: Add RPMI system MSI interrupt controller bindings
dt-bindings: Add RPMI system MSI message proxy bindings
clk: Add clock driver for the RISC-V RPMI clock service group
dt-bindings: clock: Add RPMI clock service controller bindings
dt-bindings: clock: Add RPMI clock service message proxy bindings
mailbox: Add RISC-V SBI message proxy (MPXY) based mailbox driver
...

show more ...


# 21c3896b 29-Jul-2025 Heinrich Schuchardt <heinrich.schuchardt@canonical.com>

ACPI: support BGRT table on RISC-V

The BGRT table is used to display a vendor logo in the boot process.
There is no good reason why RISC-V should not support it.

Remove the architecture constraint.

ACPI: support BGRT table on RISC-V

The BGRT table is used to display a vendor logo in the boot process.
There is no good reason why RISC-V should not support it.

Remove the architecture constraint.

Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Acked-by: Rafael J. Wysocki <rafael@kernel.org>
Reviewed-by: Sunil V L <sunilvl@ventanamicro.com>
Link: https://lore.kernel.org/r/20250729131535.522205-3-heinrich.schuchardt@canonical.com
Signed-off-by: Paul Walmsley <pjw@kernel.org>

show more ...


# 8f772955 18-Aug-2025 Sunil V L <sunilvl@ventanamicro.com>

ACPI: RISC-V: Add support for RIMT

RISC-V IO Mapping Table (RIMT) is a static ACPI table to communicate
IOMMU information to the OS. The spec is available at [1].

The changes at high level are,
a)

ACPI: RISC-V: Add support for RIMT

RISC-V IO Mapping Table (RIMT) is a static ACPI table to communicate
IOMMU information to the OS. The spec is available at [1].

The changes at high level are,
a) Initialize data structures required for IOMMU/device
configuration using the data from RIMT. Provide APIs required
for device configuration.
b) Provide an API for IOMMU drivers to register the
fwnode with RIMT data structures. This API will create a
fwnode for PCIe IOMMU.

[1] - https://github.com/riscv-non-isa/riscv-acpi-rimt

Signed-off-by: Sunil V L <sunilvl@ventanamicro.com>
Reviewed-by: Anup Patel <anup@brainfault.org>
Link: https://lore.kernel.org/r/20250818045807.763922-2-sunilvl@ventanamicro.com
Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>

show more ...


# 814eca10 09-Jun-2025 Mario Limonciello <mario.limonciello@amd.com>

ACPI: Enable CONFIG_ACPI_DEBUG by default

CONFIG_ACPI_DEBUG can be helpful for getting debug messages on OEM
systems to identify a BIOS bug. It's a relatively small size increase
to turn it on by d

ACPI: Enable CONFIG_ACPI_DEBUG by default

CONFIG_ACPI_DEBUG can be helpful for getting debug messages on OEM
systems to identify a BIOS bug. It's a relatively small size increase
to turn it on by default (50kb) and that saves asking people to enable
it when an issue comes up because it wasn't in defconfig.

Enable it by default.

Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
Link: https://patch.msgid.link/20250609030706.465202-1-superm1@kernel.org
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>

show more ...


# b9020bdb 05-May-2025 Tony Luck <tony.luck@intel.com>

ACPI: MRRM: Minimal parse of ACPI MRRM table

The resctrl file system code needs to know how many region tags
are supported. Parse the ACPI MRRM table and save the max_mem_region
value.

Provide a fu

ACPI: MRRM: Minimal parse of ACPI MRRM table

The resctrl file system code needs to know how many region tags
are supported. Parse the ACPI MRRM table and save the max_mem_region
value.

Provide a function for resctrl to collect that value.

Signed-off-by: Tony Luck <tony.luck@intel.com>
Link: https://patch.msgid.link/20250505173819.419271-2-tony.luck@intel.com
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>

show more ...


# cccf6ee0 12-Feb-2025 Xiaofei Tan <tanxiaofei@huawei.com>

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 <tanxiaofei@huawei.com>
Link: https://patch.msgid.link/20250212063408.927666-1-tanxiaofei@huawei.com
[ rjw: Changelog edits ]
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>

show more ...


# 0674188f 17-Dec-2024 Huacai Chen <chenhuacai@loongson.cn>

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 <wuxiaotian@loongson.cn>
Tested-by: Binbin Zhou <zhoubinbin@loongson.cn>
Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
Link: https://patch.msgid.link/20241217073704.3339587-1-chenhuacai@loongson.cn
[ rjw: Added Fixes: ]
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>

show more ...


# a6021aa2 11-Oct-2024 Arnd Bergmann <arnd@arndb.de>

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 <arnd@arndb.de>
Acked-by: Guenter Roeck <linux@roeck-us.net>
Acked-by: Hans de Goede <hdegoede@redhat.com>
Link: https://patch.msgid.link/20241011061948.3211423-1-arnd@kernel.org
[ rjw: Subject edits ]
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>

show more ...


# d0bb0b60 24-Sep-2024 Bibo Mao <maobibo@loongson.cn>

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 <maobibo@loongson.cn>
Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>

show more ...


# 82b8acc0 19-Mar-2024 Cezary Rojewski <cezary.rojewski@intel.com>

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 <cezary.rojewski@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>

show more ...


# c150b809 22-Mar-2024 Linus Torvalds <torvalds@linux-foundation.org>

Merge tag 'riscv-for-linus-6.9-mw2' of git://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux

Pull RISC-V updates from Palmer Dabbelt:

- Support for various vector-accelerated crypto routines

Merge tag 'riscv-for-linus-6.9-mw2' of git://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux

Pull RISC-V updates from Palmer Dabbelt:

- Support for various vector-accelerated crypto routines

- Hibernation is now enabled for portable kernel builds

- mmap_rnd_bits_max is larger on systems with larger VAs

- Support for fast GUP

- Support for membarrier-based instruction cache synchronization

- Support for the Andes hart-level interrupt controller and PMU

- Some cleanups around unaligned access speed probing and Kconfig
settings

- Support for ACPI LPI and CPPC

- Various cleanus related to barriers

- A handful of fixes

* tag 'riscv-for-linus-6.9-mw2' of git://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux: (66 commits)
riscv: Fix syscall wrapper for >word-size arguments
crypto: riscv - add vector crypto accelerated AES-CBC-CTS
crypto: riscv - parallelize AES-CBC decryption
riscv: Only flush the mm icache when setting an exec pte
riscv: Use kcalloc() instead of kzalloc()
riscv/barrier: Add missing space after ','
riscv/barrier: Consolidate fence definitions
riscv/barrier: Define RISCV_FULL_BARRIER
riscv/barrier: Define __{mb,rmb,wmb}
RISC-V: defconfig: Enable CONFIG_ACPI_CPPC_CPUFREQ
cpufreq: Move CPPC configs to common Kconfig and add RISC-V
ACPI: RISC-V: Add CPPC driver
ACPI: Enable ACPI_PROCESSOR for RISC-V
ACPI: RISC-V: Add LPI driver
cpuidle: RISC-V: Move few functions to arch/riscv
riscv: Introduce set_compat_task() in asm/compat.h
riscv: Introduce is_compat_thread() into compat.h
riscv: add compile-time test into is_compat_task()
riscv: Replace direct thread flag check with is_compat_task()
riscv: Improve arch_get_mmap_end() macro
...

show more ...


# 1d35aae7 21-Mar-2024 Linus Torvalds <torvalds@linux-foundation.org>

Merge tag 'kbuild-v6.9' of git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild

Pull Kbuild updates from Masahiro Yamada:

- Generate a list of built DTB files (arch/*/boot/dts/dtbs

Merge tag 'kbuild-v6.9' of git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild

Pull Kbuild updates from Masahiro Yamada:

- Generate a list of built DTB files (arch/*/boot/dts/dtbs-list)

- Use more threads when building Debian packages in parallel

- Fix warnings shown during the RPM kernel package uninstallation

- Change OBJECT_FILES_NON_STANDARD_*.o etc. to take a relative path to
Makefile

- Support GCC's -fmin-function-alignment flag

- Fix a null pointer dereference bug in modpost

- Add the DTB support to the RPM package

- Various fixes and cleanups in Kconfig

* tag 'kbuild-v6.9' of git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild: (67 commits)
kconfig: tests: test dependency after shuffling choices
kconfig: tests: add a test for randconfig with dependent choices
kconfig: tests: support KCONFIG_SEED for the randconfig runner
kbuild: rpm-pkg: add dtb files in kernel rpm
kconfig: remove unneeded menu_is_visible() call in conf_write_defconfig()
kconfig: check prompt for choice while parsing
kconfig: lxdialog: remove unused dialog colors
kconfig: lxdialog: fix button color for blackbg theme
modpost: fix null pointer dereference
kbuild: remove GCC's default -Wpacked-bitfield-compat flag
kbuild: unexport abs_srctree and abs_objtree
kbuild: Move -Wenum-{compare-conditional,enum-conversion} into W=1
kconfig: remove named choice support
kconfig: use linked list in get_symbol_str() to iterate over menus
kconfig: link menus to a symbol
kbuild: fix inconsistent indentation in top Makefile
kbuild: Use -fmin-function-alignment when available
alpha: merge two entries for CONFIG_ALPHA_GAMMA
alpha: merge two entries for CONFIG_ALPHA_EV4
kbuild: change DTC_FLAGS_<basetarget>.o to take the path relative to $(obj)
...

show more ...


# 359df7c5 18-Jan-2024 Sunil V L <sunilvl@ventanamicro.com>

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 <sunilvl@ventanamicro.com>
Reviewed-by: Andrew Jones <ajones@ventanamicro.com>
Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Link: https://lore.kernel.org/r/20240118062930.245937-4-sunilvl@ventanamicro.com
Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>

show more ...


# 0cc46f1a 16-Feb-2024 Rafael J. Wysocki <rafael.j.wysocki@intel.com>

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/20221227063335.61474-1-zh.nvgt@gmail.com/ # [1]
Link: https://lore.kernel.org/linux-acpi/20231111132402.4142-1-shiqiang.deng213@gmail.com/ [2]
Link: https://stackoverflow.com/questions/62849113/how-to-unload-an-overlay-loaded-using-acpi-config-sysfs # [3]
Reported-by: Hang Zhang <zh.nvgt@gmail.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Zhang Rui <rui.zhang@intel.com>
Reviewed-by: Kees Cook <keescook@chromium.org>

show more ...


# cd14b018 11-Feb-2024 Masahiro Yamada <masahiroy@kernel.org>

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 <masahiroy@kernel.org>

show more ...


# 80955ae9 18-Jan-2024 Linus Torvalds <torvalds@linux-foundation.org>

Merge tag 'driver-core-6.8-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core

Pull driver core updates from Greg KH:
"Here are the set of driver core and kernfs changes for 6.

Merge tag 'driver-core-6.8-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core

Pull driver core updates from Greg KH:
"Here are the set of driver core and kernfs changes for 6.8-rc1.
Nothing major in here this release cycle, just lots of small cleanups
and some tweaks on kernfs that in the very end, got reverted and will
come back in a safer way next release cycle.

Included in here are:

- more driver core 'const' cleanups and fixes

- fw_devlink=rpm is now the default behavior

- kernfs tiny changes to remove some string functions

- cpu handling in the driver core is updated to work better on many
systems that add topologies and cpus after booting

- other minor changes and cleanups

All of the cpu handling patches have been acked by the respective
maintainers and are coming in here in one series. Everything has been
in linux-next for a while with no reported issues"

* tag 'driver-core-6.8-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core: (51 commits)
Revert "kernfs: convert kernfs_idr_lock to an irq safe raw spinlock"
kernfs: convert kernfs_idr_lock to an irq safe raw spinlock
class: fix use-after-free in class_register()
PM: clk: make pm_clk_add_notifier() take a const pointer
EDAC: constantify the struct bus_type usage
kernfs: fix reference to renamed function
driver core: device.h: fix Excess kernel-doc description warning
driver core: class: fix Excess kernel-doc description warning
driver core: mark remaining local bus_type variables as const
driver core: container: make container_subsys const
driver core: bus: constantify subsys_register() calls
driver core: bus: make bus_sort_breadthfirst() take a const pointer
kernfs: d_obtain_alias(NULL) will do the right thing...
driver core: Better advertise dev_err_probe()
kernfs: Convert kernfs_path_from_node_locked() from strlcpy() to strscpy()
kernfs: Convert kernfs_name_locked() from strlcpy() to strscpy()
kernfs: Convert kernfs_walk_ns() from strlcpy() to strscpy()
initramfs: Expose retained initrd as sysfs file
fs/kernfs/dir: obey S_ISGID
kernel/cgroup: use kernfs_create_dir_ns()
...

show more ...


# a02f66bb 21-Nov-2023 James Morse <james.morse@arm.com>

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 <james.morse@arm.com>
Reviewed-by: Shaoqin Huang <shahuang@redhat.com>
Reviewed-by: Gavin Shan <gshan@redhat.com>
Signed-off-by: "Russell King (Oracle)" <rmk+kernel@armlinux.org.uk>
Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Thomas Gleixner <tglx@linutronix.de>
Link: https://lore.kernel.org/r/E1r5R31-00Csyt-Jq@rmk-PC.armlinux.org.uk
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

show more ...


# f4750798 17-Oct-2023 Rafael J. Wysocki <rafael.j.wysocki@intel.com>

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 <rafael.j.wysocki@intel.com>

show more ...


# b8cc56d0 05-Nov-2023 Linus Torvalds <torvalds@linux-foundation.org>

Merge tag 'cxl-for-6.7' of git://git.kernel.org/pub/scm/linux/kernel/git/cxl/cxl

Pull CXL (Compute Express Link) updates from Dan Williams:
"The main new functionality this time is work to allow Li

Merge tag 'cxl-for-6.7' of git://git.kernel.org/pub/scm/linux/kernel/git/cxl/cxl

Pull CXL (Compute Express Link) updates from Dan Williams:
"The main new functionality this time is work to allow Linux to
natively handle CXL link protocol errors signalled via PCIe AER for
current generation CXL platforms. This required some enlightenment of
the PCIe AER core to workaround the fact that current generation RCH
(Restricted CXL Host) platforms physically hide topology details and
registers via a mechanism called RCRB (Root Complex Register Block).

The next major highlight is reworks to address bugs in parsing region
configurations for next generation VH (Virtual Host) topologies. The
old broken algorithm is replaced with a simpler one that significantly
increases the number of region configurations supported by Linux. This
is again relevant for error handling so that forward and reverse
address translation of memory errors can be carried out by Linux for
memory regions instantiated by platform firmware.

As for other cross-tree work, the ACPI table parsing code has been
refactored for reuse parsing the "CDAT" structure which is an
ACPI-like data structure that is reported by CXL devices. That work is
in preparation for v6.8 support for CXL QoS. Think of this as dynamic
generation of NUMA node topology information generated by Linux rather
than platform firmware.

Lastly, a number of internal object lifetime issues have been resolved
along with misc. fixes and feature updates (decoders_committed sysfs
ABI).

Summary:

- Add support for RCH (Restricted CXL Host) Error recovery

- Fix several region assembly bugs

- Fix mem-device lifetime issues relative to the sanitize command and
RCH topology.

- Refactor ACPI table parsing for CDAT parsing re-use in preparation
for CXL QOS support"

* tag 'cxl-for-6.7' of git://git.kernel.org/pub/scm/linux/kernel/git/cxl/cxl: (50 commits)
lib/fw_table: Remove acpi_parse_entries_array() export
cxl/pci: Change CXL AER support check to use native AER
cxl/hdm: Remove broken error path
cxl/hdm: Fix && vs || bug
acpi: Move common tables helper functions to common lib
cxl: Add support for reading CXL switch CDAT table
cxl: Add checksum verification to CDAT from CXL
cxl: Export QTG ids from CFMWS to sysfs as qos_class attribute
cxl: Add decoders_committed sysfs attribute to cxl_port
cxl: Add cxl_decoders_committed() helper
cxl/core/regs: Rework cxl_map_pmu_regs() to use map->dev for devm
cxl/core/regs: Rename phys_addr in cxl_map_component_regs()
PCI/AER: Unmask RCEC internal errors to enable RCH downstream port error handling
PCI/AER: Forward RCH downstream port-detected errors to the CXL.mem dev handler
cxl/pci: Disable root port interrupts in RCH mode
cxl/pci: Add RCH downstream port error logging
cxl/pci: Map RCH downstream AER registers for logging protocol errors
cxl/pci: Update CXL error logging to use RAS register address
PCI/AER: Refactor cper_print_aer() for use by CXL driver module
cxl/pci: Add RCH downstream port AER register discovery
...

show more ...


# a103f466 12-Oct-2023 Dave Jiang <dave.jiang@intel.com>

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" <rafael@kernel.org>
Reviewed-by: Hanjun Guo <guohanjun@huawei.com>
Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Signed-off-by: Dave Jiang <dave.jiang@intel.com>
Acked-by: "Rafael J. Wysocki" <rafael.j.wysocki@intel.com>
Link: https://lore.kernel.org/r/169713683430.2205276.17899451119920103445.stgit@djiang5-mobl3
Signed-off-by: Dan Williams <dan.j.williams@intel.com>

show more ...


# cf8e8658 20-Oct-2022 Ard Biesheuvel <ardb@kernel.org>

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/0075883c-7c51-00f5-2c2d-5119c1820410@web.de/
[2] https://gridcf.org/gct-docs/latest/index.html
[3] https://cfarm.tetaneutral.net/machines/list/
[4] https://lore.kernel.org/all/87bkiilpc4.fsf@mid.deneb.enyo.de/
[5] https://lore.kernel.org/all/ff58a3e76e5102c94bb5946d99187b358def688a.camel@physik.fu-berlin.de/

Acked-by: Tony Luck <tony.luck@intel.com>
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>

show more ...


# 5894cf57 02-Jul-2023 Ard Biesheuvel <ardb@kernel.org>

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 <rafael.j.wysocki@intel.com>
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>

show more ...


12345678910>>...17