History log of /linux-6.15/drivers/acpi/prmt.c (Results 1 – 15 of 15)
Revision (<<< Hide revision tags) (Show revision tags >>>) Date Author Comments
Revision tags: v6.15, v6.15-rc7, v6.15-rc6, v6.15-rc5, v6.15-rc4, v6.15-rc3, v6.15-rc2, v6.15-rc1, v6.14, v6.14-rc7, v6.14-rc6, v6.14-rc5, v6.14-rc4, v6.14-rc3, v6.14-rc2, v6.14-rc1
# 7f5704b6 26-Jan-2025 Aubrey Li <[email protected]>

ACPI: PRM: Remove unnecessary strict handler address checks

Commit 088984c8d54c ("ACPI: PRM: Find EFI_MEMORY_RUNTIME block for PRM
handler and context") added unnecessary strict handler address chec

ACPI: PRM: Remove unnecessary strict handler address checks

Commit 088984c8d54c ("ACPI: PRM: Find EFI_MEMORY_RUNTIME block for PRM
handler and context") added unnecessary strict handler address checks,
causing the PRM module to fail in translating memory error addresses.

Both static data buffer address and ACPI parameter buffer address may
be NULL if they are not needed, as described in section 4.1.2 PRM Handler
Information Structure of Platform Runtime Mechanism specification [1].

Here are two examples from real hardware:

----PRMT.dsl----

- staic data address is not used
[10Ch 0268 2] Revision : 0000
[10Eh 0270 2] Length : 002C
[110h 0272 16] Handler GUID : F6A58D47-E04F-4F5A-86B8-2A50D4AA109B
[120h 0288 8] Handler address : 0000000065CE51F4
[128h 0296 8] Satic Data Address : 0000000000000000
[130h 0304 8] ACPI Parameter Address : 000000006522A718

- ACPI parameter address is not used
[1B0h 0432 2] Revision : 0000
[1B2h 0434 2] Length : 002C
[1B4h 0436 16] Handler GUID : 657E8AE6-A8FC-4877-BB28-42E7DE1899A5
[1C4h 0452 8] Handler address : 0000000065C567C8
[1CCh 0460 8] Satic Data Address : 000000006113FB98
[1D4h 0468 8] ACPI Parameter Address : 0000000000000000

Fixes: 088984c8d54c ("ACPI: PRM: Find EFI_MEMORY_RUNTIME block for PRM handler and context")
Reported-and-tested-by: Shi Liu <[email protected]>
Cc: All applicable <[email protected]>
Signed-off-by: Aubrey Li <[email protected]>
Link: https://uefi.org/sites/default/files/resources/Platform%20Runtime%20Mechanism%20-%20with%20legal%20notice.pdf # [1]
Reviewed-by: Koba Ko <[email protected]>
Acked-by: Ard Biesheuvel <[email protected]>
Link: https://patch.msgid.link/[email protected]
[ rjw: Minor changelog edits ]
Signed-off-by: Rafael J. Wysocki <[email protected]>

show more ...


Revision tags: v6.13, v6.13-rc7, v6.13-rc6, v6.13-rc5, v6.13-rc4, v6.13-rc3, v6.13-rc2, v6.13-rc1, v6.12, v6.12-rc7, v6.12-rc6, v6.12-rc5
# 3d1c6512 24-Oct-2024 Dan Carpenter <[email protected]>

ACPI: PRM: Clean up guid type in struct prm_handler_info

Clang 19 prints a warning when we pass &th->guid to efi_pa_va_lookup():

drivers/acpi/prmt.c:156:29: error: passing 1-byte aligned argument t

ACPI: PRM: Clean up guid type in struct prm_handler_info

Clang 19 prints a warning when we pass &th->guid to efi_pa_va_lookup():

drivers/acpi/prmt.c:156:29: error: passing 1-byte aligned argument to
4-byte aligned parameter 1 of 'efi_pa_va_lookup' may result in an
unaligned pointer access [-Werror,-Walign-mismatch]
156 | (void *)efi_pa_va_lookup(&th->guid, handler_info->handler_address);
| ^

The problem is that efi_pa_va_lookup() takes a efi_guid_t and &th->guid
is a regular guid_t. The difference between the two types is the
alignment. efi_guid_t is a typedef.

typedef guid_t efi_guid_t __aligned(__alignof__(u32));

It's possible that this a bug in Clang 19. Even though the alignment of
&th->guid is not explicitly specified, it will still end up being aligned
at 4 or 8 bytes.

Anyway, as Ard points out, it's cleaner to change guid to efi_guid_t type
and that also makes the warning go away.

Fixes: 088984c8d54c ("ACPI: PRM: Find EFI_MEMORY_RUNTIME block for PRM handler and context")
Reported-by: Linux Kernel Functional Testing <[email protected]>
Suggested-by: Ard Biesheuvel <[email protected]>
Signed-off-by: Dan Carpenter <[email protected]>
Tested-by: Paul E. McKenney <[email protected]>
Acked-by: Ard Biesheuvel <[email protected]>
Link: https://patch.msgid.link/[email protected]
[ rjw: Subject edit ]
Signed-off-by: Rafael J. Wysocki <[email protected]>

show more ...


Revision tags: v6.12-rc4, v6.12-rc3
# 088984c8 12-Oct-2024 Koba Ko <[email protected]>

ACPI: PRM: Find EFI_MEMORY_RUNTIME block for PRM handler and context

PRMT needs to find the correct type of block to translate the PA-VA
mapping for EFI runtime services.

The issue arises because t

ACPI: PRM: Find EFI_MEMORY_RUNTIME block for PRM handler and context

PRMT needs to find the correct type of block to translate the PA-VA
mapping for EFI runtime services.

The issue arises because the PRMT is finding a block of type
EFI_CONVENTIONAL_MEMORY, which is not appropriate for runtime services
as described in Section 2.2.2 (Runtime Services) of the UEFI
Specification [1]. Since the PRM handler is a type of runtime service,
this causes an exception when the PRM handler is called.

[Firmware Bug]: Unable to handle paging request in EFI runtime service
WARNING: CPU: 22 PID: 4330 at drivers/firmware/efi/runtime-wrappers.c:341
__efi_queue_work+0x11c/0x170
Call trace:

Let PRMT find a block with EFI_MEMORY_RUNTIME for PRM handler and PRM
context.

If no suitable block is found, a warning message will be printed, but
the procedure continues to manage the next PRM handler.

However, if the PRM handler is actually called without proper allocation,
it would result in a failure during error handling.

By using the correct memory types for runtime services, ensure that the
PRM handler and the context are properly mapped in the virtual address
space during runtime, preventing the paging request error.

The issue is really that only memory that has been remapped for runtime
by the firmware can be used by the PRM handler, and so the region needs
to have the EFI_MEMORY_RUNTIME attribute.

Link: https://uefi.org/sites/default/files/resources/UEFI_Spec_2_10_Aug29.pdf # [1]
Fixes: cefc7ca46235 ("ACPI: PRM: implement OperationRegion handler for the PlatformRtMechanism subtype")
Cc: All applicable <[email protected]>
Signed-off-by: Koba Ko <[email protected]>
Reviewed-by: Matthew R. Ochs <[email protected]>
Reviewed-by: Zhang Rui <[email protected]>
Reviewed-by: Ard Biesheuvel <[email protected]>
Link: https://patch.msgid.link/[email protected]
[ rjw: Subject and changelog edits ]
Signed-off-by: Rafael J. Wysocki <[email protected]>

show more ...


Revision tags: v6.12-rc2, v6.12-rc1, v6.11, v6.11-rc7, v6.11-rc6, v6.11-rc5, v6.11-rc4, v6.11-rc3, v6.11-rc2
# f0fcdd2c 30-Jul-2024 John Allen <[email protected]>

ACPI: PRM: Add PRM handler direct call support

Platform Runtime Mechanism (PRM) handlers can be invoked from either the AML
interpreter or directly by an OS driver. Implement the latter.

[ bp: Ma

ACPI: PRM: Add PRM handler direct call support

Platform Runtime Mechanism (PRM) handlers can be invoked from either the AML
interpreter or directly by an OS driver. Implement the latter.

[ bp: Massage commit message. ]

Signed-off-by: John Allen <[email protected]>
Signed-off-by: Borislav Petkov (AMD) <[email protected]>
Reviewed-by: Yazen Ghannam <[email protected]>
Reviewed-by: Ard Biesheuvel <[email protected]>
Acked-by: Rafael J. Wysocki <[email protected]>
Link: https://lore.kernel.org/r/[email protected]

show more ...


Revision tags: v6.11-rc1, v6.10, v6.10-rc7, v6.10-rc6, v6.10-rc5, v6.10-rc4, v6.10-rc3, v6.10-rc2, v6.10-rc1, v6.9, v6.9-rc7, v6.9-rc6, v6.9-rc5, v6.9-rc4, v6.9-rc3, v6.9-rc2, v6.9-rc1, v6.8, v6.8-rc7, v6.8-rc6, v6.8-rc5, v6.8-rc4, v6.8-rc3, v6.8-rc2, v6.8-rc1, v6.7, v6.7-rc8, v6.7-rc7, v6.7-rc6, v6.7-rc5, v6.7-rc4, v6.7-rc3, v6.7-rc2, v6.7-rc1, v6.6, v6.6-rc7, v6.6-rc6, v6.6-rc5, v6.6-rc4, v6.6-rc3
# 2e893457 22-Sep-2023 Kees Cook <[email protected]>

ACPI: PRM: Annotate struct prm_module_info with __counted_by

Prepare for the coming implementation by GCC and Clang of the __counted_by
attribute. Flexible array members annotated with __counted_by

ACPI: PRM: Annotate struct prm_module_info with __counted_by

Prepare for the coming implementation by GCC and Clang of the __counted_by
attribute. Flexible array members annotated with __counted_by can have
their accesses bounds-checked at run-time checking via CONFIG_UBSAN_BOUNDS
(for array indexing) and CONFIG_FORTIFY_SOURCE (for strcpy/memcpy-family
functions).

As found with Coccinelle[1], add __counted_by for struct prm_module_info.

Link: https://github.com/kees/kernel-tools/blob/trunk/coccinelle/examples/counted_by.cocci # [1]
Signed-off-by: Kees Cook <[email protected]>
Reviewed-by: Gustavo A. R. Silva <[email protected]>
Signed-off-by: Rafael J. Wysocki <[email protected]>

show more ...


Revision tags: v6.6-rc2, v6.6-rc1, v6.5, v6.5-rc7, v6.5-rc6, v6.5-rc5, v6.5-rc4, v6.5-rc3, v6.5-rc2, v6.5-rc1
# 5894cf57 02-Jul-2023 Ard Biesheuvel <[email protected]>

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


# e38abdab 02-Jul-2023 Ard Biesheuvel <[email protected]>

efi/runtime-wrappers: Remove duplicated macro for service returning void

__efi_call_virt() exists as an alternative for efi_call_virt() for the
sole reason that ResetSystem() returns void, and so we

efi/runtime-wrappers: Remove duplicated macro for service returning void

__efi_call_virt() exists as an alternative for efi_call_virt() for the
sole reason that ResetSystem() returns void, and so we cannot use a call
to it in the RHS of an assignment.

Given that there is only a single user, let's drop the macro, and expand
it into the caller. That way, the remaining macro can be tightened
somewhat in terms of type safety too.

Note that the use of typeof() on the runtime service invocation does not
result in an actual call being made, but it does require a few pointer
types to be fixed up and converted into the proper function pointer
prototypes.

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

show more ...


Revision tags: v6.4, v6.4-rc7, v6.4-rc6, v6.4-rc5, v6.4-rc4, v6.4-rc3, v6.4-rc2, v6.4-rc1, v6.3, v6.3-rc7, v6.3-rc6, v6.3-rc5, v6.3-rc4, v6.3-rc3, v6.3-rc2, v6.3-rc1, v6.2, v6.2-rc8, v6.2-rc7, v6.2-rc6, v6.2-rc5, v6.2-rc4
# 182da6f2 12-Jan-2023 Ard Biesheuvel <[email protected]>

ACPI: PRM: Check whether EFI runtime is available

The ACPI PRM address space handler calls efi_call_virt_pointer() to
execute PRM firmware code, but doing so is only permitted when the EFI
runtime e

ACPI: PRM: Check whether EFI runtime is available

The ACPI PRM address space handler calls efi_call_virt_pointer() to
execute PRM firmware code, but doing so is only permitted when the EFI
runtime environment is available. Otherwise, such calls are guaranteed
to result in a crash, and must therefore be avoided.

Given that the EFI runtime services may become unavailable after a crash
occurring in the firmware, we need to check this each time the PRM
address space handler is invoked. If the EFI runtime services were not
available at registration time to being with, don't install the address
space handler at all.

Fixes: cefc7ca46235 ("ACPI: PRM: implement OperationRegion handler for the PlatformRtMechanism subtype")
Signed-off-by: Ard Biesheuvel <[email protected]>
Cc: All applicable <[email protected]>
Signed-off-by: Rafael J. Wysocki <[email protected]>

show more ...


Revision tags: v6.2-rc3, v6.2-rc2, v6.2-rc1, v6.1, v6.1-rc8, v6.1-rc7, v6.1-rc6, v6.1-rc5, v6.1-rc4, v6.1-rc3, v6.1-rc2, v6.1-rc1, v6.0, v6.0-rc7, v6.0-rc6, v6.0-rc5, v6.0-rc4, v6.0-rc3, v6.0-rc2, v6.0-rc1, v5.19, v5.19-rc8, v5.19-rc7, v5.19-rc6, v5.19-rc5
# 353efd5e 28-Jun-2022 Sudeep Holla <[email protected]>

ACPI: PRM: Change handler_addr type to void pointer

handler_addr is a virtual address passed to efi_call_virt_pointer.
While x86 currently type cast it into the pointer in it's arch specific
arch_ef

ACPI: PRM: Change handler_addr type to void pointer

handler_addr is a virtual address passed to efi_call_virt_pointer.
While x86 currently type cast it into the pointer in it's arch specific
arch_efi_call_virt() implementation, ARM64 is restrictive for right
reasons.

Convert the handler_addr type from u64 to void pointer.

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

show more ...


Revision tags: v5.19-rc4, v5.19-rc3, v5.19-rc2, v5.19-rc1, v5.18, v5.18-rc7, v5.18-rc6, v5.18-rc5, v5.18-rc4, v5.18-rc3, v5.18-rc2, v5.18-rc1, v5.17, v5.17-rc8, v5.17-rc7, v5.17-rc6, v5.17-rc5, v5.17-rc4, v5.17-rc3, v5.17-rc2, v5.17-rc1, v5.16, v5.16-rc8, v5.16-rc7, v5.16-rc6, v5.16-rc5, v5.16-rc4, v5.16-rc3, v5.16-rc2, v5.16-rc1, v5.15, v5.15-rc7
# c52ca713 20-Oct-2021 Aubrey Li <[email protected]>

ACPI: PRM: Handle memory allocation and memory remap failure

Handle memory allocation and memory remap failure in acpi_parse_prmt()
when system runs out of memory to avoid the potential NULL pointer

ACPI: PRM: Handle memory allocation and memory remap failure

Handle memory allocation and memory remap failure in acpi_parse_prmt()
when system runs out of memory to avoid the potential NULL pointer
dereference errors.

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

show more ...


# caa2bd07 20-Oct-2021 Aubrey Li <[email protected]>

ACPI: PRM: Remove unnecessary blank lines

Just remove unnecessary blank lines, no other code changes

Signed-off-by: Aubrey Li <[email protected]>
Signed-off-by: Rafael J. Wysocki <rafael.j.

ACPI: PRM: Remove unnecessary blank lines

Just remove unnecessary blank lines, no other code changes

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

show more ...


Revision tags: v5.15-rc6, v5.15-rc5, v5.15-rc4, v5.15-rc3, v5.15-rc2, v5.15-rc1
# 3265cc3e 08-Sep-2021 Aubrey Li <[email protected]>

ACPI: PRM: Find PRMT table before parsing it

Find and verify PRMT before parsing it, which eliminates a
warning on machines without PRMT:

[ 7.197173] ACPI: PRMT not present

Fixes: cefc7ca46235

ACPI: PRM: Find PRMT table before parsing it

Find and verify PRMT before parsing it, which eliminates a
warning on machines without PRMT:

[ 7.197173] ACPI: PRMT not present

Fixes: cefc7ca46235 ("ACPI: PRM: implement OperationRegion handler for the PlatformRtMechanism subtype")
Signed-off-by: Aubrey Li <[email protected]>
Tested-by: Paul Menzel <[email protected]>
Cc: 5.14+ <[email protected]> # 5.14+
[ rjw: Subject and changelog edits ]
Signed-off-by: Rafael J. Wysocki <[email protected]>

show more ...


Revision tags: v5.14, v5.14-rc7, v5.14-rc6, v5.14-rc5
# 2bbfa0ad 06-Aug-2021 Aubrey Li <[email protected]>

ACPI: PRM: Deal with table not present or no module found

On the system PRMT table is not present, dmesg output:

$ dmesg | grep PRM
[ 1.532237] ACPI: PRMT not present
[ 1.532237] PRM: foun

ACPI: PRM: Deal with table not present or no module found

On the system PRMT table is not present, dmesg output:

$ dmesg | grep PRM
[ 1.532237] ACPI: PRMT not present
[ 1.532237] PRM: found 4294967277 modules

The result of acpi_table_parse_entries need to be checked and return
immediately if PRMT table is not present or no PRM module found.

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

show more ...


Revision tags: v5.14-rc4, v5.14-rc3, v5.14-rc2, v5.14-rc1, v5.13, v5.13-rc7
# d7a188bb 15-Jun-2021 Wei Yongjun <[email protected]>

ACPI: PRM: make symbol 'prm_module_list' static

The sparse tool complains as follows:

drivers/acpi/prmt.c:53:1: warning:
symbol 'prm_module_list' was not declared. Should it be static?

This symbo

ACPI: PRM: make symbol 'prm_module_list' static

The sparse tool complains as follows:

drivers/acpi/prmt.c:53:1: warning:
symbol 'prm_module_list' was not declared. Should it be static?

This symbol is not used outside of prmt.c, so marks it static.

Fixes: cefc7ca46235 ("ACPI: PRM: implement OperationRegion handler for the PlatformRtMechanism subtype")
Reported-by: Hulk Robot <[email protected]>
Signed-off-by: Wei Yongjun <[email protected]>
Signed-off-by: Rafael J. Wysocki <[email protected]>

show more ...


Revision tags: v5.13-rc6
# cefc7ca4 10-Jun-2021 Erik Kaneda <[email protected]>

ACPI: PRM: implement OperationRegion handler for the PlatformRtMechanism subtype

Platform Runtime Mechanism (PRM) is a firmware interface that exposes
a set of binary executables that can either be

ACPI: PRM: implement OperationRegion handler for the PlatformRtMechanism subtype

Platform Runtime Mechanism (PRM) is a firmware interface that exposes
a set of binary executables that can either be called from the AML
interpreter or device drivers by bypassing the AML interpreter.
This change implements the AML interpreter path.

According to the specification [1], PRM services are listed in an
ACPI table called the PRMT. This patch parses module and handler
information listed in the PRMT and registers the PlatformRtMechanism
OpRegion handler before ACPI tables are loaded.

Each service is defined by a 16-byte GUID and called from writing a
26-byte ASL buffer containing the identifier to a FieldUnit object
defined inside a PlatformRtMechanism OperationRegion.

OperationRegion (PRMR, PlatformRtMechanism, 0, 26)
Field (PRMR, BufferAcc, NoLock, Preserve)
{
PRMF, 208 // Write to this field to invoke the OperationRegion Handler
}

The 26-byte ASL buffer is defined as the following:

Byte Offset Byte Length Description
=============================================================
0 1 PRM OperationRegion handler status
1 8 PRM service status
9 1 PRM command
10 16 PRM handler GUID

The ASL caller fills out a 26-byte buffer containing the PRM command
and the PRM handler GUID like so:

/* Local0 is the PRM data buffer */
Local0 = buffer (26){}

/* Create byte fields over the buffer */
CreateByteField (Local0, 0x9, CMD)
CreateField (Local0, 0x50, 0x80, GUID)

/* Fill in the command and data fields of the data buffer */
CMD = 0 // run command
GUID = ToUUID("xxxx-xx-xxx-xxxx")

/*
* Invoke PRM service with an ID that matches GUID and save the
* result.
*/
Local0 = (\_SB.PRMT.PRMF = Local0)

Byte offset 0 - 8 are written by the handler as a status passed back to AML
and used by ASL like so:

/* Create byte fields over the buffer */
CreateByteField (Local0, 0x0, PSTA)
CreateQWordField (Local0, 0x1, USTA)

In this ASL code, PSTA contains a status from the OperationRegion and
USTA contains a status from the PRM service.

The 26-byte buffer is recieved by acpi_platformrt_space_handler. This
handler will look at the command value and the handler guid and take
the approperiate actions.

Command value Action
=====================================================================
0 Run the PRM service indicated by the PRM handler
GUID (bytes 10-26)

1 Prevent PRM runtime updates from happening to the
service's parent module

2 Allow PRM updates from happening to the service's parent module

This patch enables command value 0.

Link: https://uefi.org/sites/default/files/resources/Platform%20Runtime%20Mechanism%20-%20with%20legal%20notice.pdf # [1]
Signed-off-by: Erik Kaneda <[email protected]>
[ rjw: Subject and changelog edits ]
Signed-off-by: Rafael J. Wysocki <[email protected]>

show more ...