kernel/linux.git/arch/s390/include/asm/sclp.h, branch linux-7.0.y

s390: Replace ASSEMBLY with ASSEMBLER in non-uapi headers

2025-06-16T14:23:02+00:00

While the GCC and Clang compilers already define __ASSEMBLER__ automatically when compiling assembler code, __ASSEMBLY__ is a macro that only gets defined by the Makefiles in the kernel. This is bad since macros starting with two underscores are names that are reserved by the C language. It can also be very confusing for the developers when switching between userspace and kernelspace coding, or when dealing with uapi headers that rather should use __ASSEMBLER__ instead. So let's now standardize on the __ASSEMBLER__ macro that is provided by the compilers. This is a completely mechanical patch (done with a simple "sed -i" statement), with some manual fixups done later while rebasing the patch. Signed-off-by: Thomas Huth Acked-by: Heiko Carstens Link: https://lore.kernel.org/r/20250611140046.137739-3-thuth@redhat.com Signed-off-by: Alexander Gordeev

s390/tlb: Convert MACHINE_HAS_TLB_GUEST to machine_has_tlb_guest()

2025-03-04T16:18:06+00:00

Use static branch(es) to implement and use machine_has_tlb_guest() instead of a runtime check via MACHINE_HAS_TLB_GUEST. Also add sclp_early_detect_machine_features() in order to allow for feature detection from the decompressor. Reviewed-by: Vasily Gorbik Signed-off-by: Heiko Carstens Signed-off-by: Vasily Gorbik

s390/sclp: Initialize sclp subsystem via arch_cpu_finalize_init()

2025-01-28T16:38:46+00:00

With the switch to GENERIC_CPU_DEVICES an early call to the sclp subsystem was added to smp_prepare_cpus(). This will usually succeed since the sclp subsystem is implicitly initialized early enough if an sclp based console is present. If no such console is present the initialization happens with an arch_initcall(); in such cases calls to the sclp subsystem will fail. For CPU detection this means that the fallback sigp loop will be used permanently to detect CPUs instead of the preferred READ_CPU_INFO sclp request. Fix this by adding an explicit early sclp_init() call via arch_cpu_finalize_init(). Reported-by: Sheshu Ramanandan Fixes: 4a39f12e753d ("s390/smp: Switch to GENERIC_CPU_DEVICES") Reviewed-by: Peter Oberparleiter Signed-off-by: Heiko Carstens Signed-off-by: Alexander Gordeev

s390/diag: Add memory topology information via diag310

2025-01-15T12:59:08+00:00

Introduce diag310 and memory topology related subcodes. Provide memory topology information obtanied from diag310 to userspace via diag ioctl. Signed-off-by: Mete Durlu Reviewed-by: Heiko Carstens Signed-off-by: Alexander Gordeev

Merge branch 'pci-device-recovery' into features

2024-12-18T15:06:24+00:00

Niklas Schnelle says: =================== This patch series enhances the introspectability of the PCI device recovery for firmware. Until now when Linux performs recovery in response to a firmware error report. For example, until now firmware debug data would have no indication if the recovery was successfull or if it failed, for example due to KVM pass-through. Improve on this by reporting recovery status as well as some debug information such as device driver name and s390dbf/pci_msg/sprintf logs via the SCLP Write Event Data Action Qualifier 2 (Log Data provided) mechanism. =================== Signed-off-by: Alexander Gordeev

s390/diag324: Retrieve power readings via diag 0x324

2024-12-17T11:46:14+00:00

Retrieve electrical power readings for resources in a computing environment via diag 0x324. diag 0x324 stores the power readings in the power information block (pib). Provide power readings from pib via diag324 ioctl interface. diag324 ioctl provides new pib to the user only if the threshold time has passed since the last call. Otherwise, cache data is returned. When there are no active readers, cleanup of pib buffer is performed. Reviewed-by: Heiko Carstens Signed-off-by: Sumanth Korikkar Signed-off-by: Alexander Gordeev

s390/pci: Report PCI error recovery results via SCLP

2024-12-16T15:14:26+00:00

Add a mechanism with which the status of PCI error recovery runs is reported to the platform. Together with the status supply additional information that may aid in problem determination. Reviewed-by: Halil Pasic Signed-off-by: Niklas Schnelle Signed-off-by: Alexander Gordeev

s390/wti: Introduce infrastructure for warning track interrupt

2024-08-29T20:56:34+00:00

The warning-track interrupt (wti) provides a notification that the receiving CPU will be pre-empted from its physical CPU within a short time frame. This time frame is called grace period and depends on the machine type. Giving up the CPU on time may prevent a task to get stuck while holding a resource. Reviewed-by: Heiko Carstens Reviewed-by: Mete Durlu Signed-off-by: Tobias Huschle Signed-off-by: Vasily Gorbik

s390/sclp: Diag204 busy indication facility detection

2024-07-10T17:50:44+00:00

Detect diag204 busy indication facility. Acked-by: Heiko Carstens Reviewed-by: Tobias Huschle Signed-off-by: Mete Durlu Signed-off-by: Vasily Gorbik

s390: add support for user-defined certificates

2023-07-24T10:12:21+00:00

Enable receiving the user-defined certificates from the s390x hypervisor via new diagnose 0x320 calls, and make them available to the Linux root user as 'cert_store_key' type keys in a so-called 'cert_store' keyring. New user-space interfaces: /sys/firmware/cert_store/refresh Writing to this attribute re-fetches certificates via DIAG 0x320 /sys/firmware/cert_store/cs_status Reading from this attribute returns either of: "uninitialized" If no certificate has been retrieved yet "ok" If certificates have been successfully retrieved "failed ()" If certificate retrieval failed with reason code New debug trace areas: /sys/kernel/debug/s390dbf/cert_store_msg /sys/kernel/debug/s390dbf/cert_store_hexdump Usage example: To initiate request for certificates available to the system as root: $ echo 1 > /sys/firmware/cert_store/refresh Upon success the '/sys/firmware/cert_store/cs_status' contains the value 'ok'. $ cat /sys/firmware/cert_store/cs_status ok Get the ID of the keyring 'cert_store': $ keyctl search @us keyring cert_store OR $ keyctl link @us @s; keyctl request keyring cert_store Obtain list of IDs of certificates: $ keyctl rlist Display certificate content as hex-dump: $ keyctl read Read certificate contents as binary data: $ keyctl pipe >cert_data Display certificate description: $ keyctl describe The certificate description has the following format: <64 bytes certificate name in EBCDIC> ':' ':' The certificate description in /proc/keys has certificate name represented in ASCII. Users can read but cannot update the content of the certificate. Signed-off-by: Anastasia Eskova Reviewed-by: Peter Oberparleiter Acked-by: Heiko Carstens Signed-off-by: Heiko Carstens