| #
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 ...
|