tracing: Disable branch profiling in noinstr code

CONFIG_TRACE_BRANCH_PROFILING inserts a call to ftrace_likely_update()
for each use of likely() or unlikely(). That breaks noinstr rules if
the aff

tracing: Disable branch profiling in noinstr code

CONFIG_TRACE_BRANCH_PROFILING inserts a call to ftrace_likely_update()
for each use of likely() or unlikely(). That breaks noinstr rules if
the affected function is annotated as noinstr.

Disable branch profiling for files with noinstr functions. In addition
to some individual files, this also includes the entire arch/x86
subtree, as well as the kernel/entry, drivers/cpuidle, and drivers/idle
directories, all of which are noinstr-heavy.

Due to the nature of how sched binaries are built by combining multiple
.c files into one, branch profiling is disabled more broadly across the
sched code than would otherwise be needed.

This fixes many warnings like the following:

vmlinux.o: warning: objtool: do_syscall_64+0x40: call to ftrace_likely_update() leaves .noinstr.text section
vmlinux.o: warning: objtool: __rdgsbase_inactive+0x33: call to ftrace_likely_update() leaves .noinstr.text section
vmlinux.o: warning: objtool: handle_bug.isra.0+0x198: call to ftrace_likely_update() leaves .noinstr.text section
...

Reported-by: Ingo Molnar <[email protected]>
Suggested-by: Steven Rostedt <[email protected]>
Signed-off-by: Josh Poimboeuf <[email protected]>
Signed-off-by: Ingo Molnar <[email protected]>
Acked-by: Thomas Gleixner <[email protected]>
Cc: Linus Torvalds <[email protected]>
Link: https://lore.kernel.org/r/fb94fc9303d48a5ed370498f54500cc4c338eb6d.1742586676.git.jpoimboe@kernel.org

show more ...

ACPI: EC: make EC support compile-time conditional

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

Make this a user-visible configuratio

ACPI: EC: make EC support compile-time conditional

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

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

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

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

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

show more ...

ACPI: fan: Add hwmon support

Currently, the driver does only support a custom sysfs
interface to allow userspace to read the fan speed.
Add support for the standard hwmon interface so users
can read

ACPI: fan: Add hwmon support

Currently, the driver does only support a custom sysfs
interface to allow userspace to read the fan speed.
Add support for the standard hwmon interface so users
can read the fan speed with standard tools like "sensors".

Reviewed-by: Andy Shevchenko <[email protected]>
Signed-off-by: Armin Wolf <[email protected]>
Signed-off-by: Rafael J. Wysocki <[email protected]>

show more ...

ACPI: x86: Move LPSS to x86 folder

LPSS is built solely for x86, move it to the respective folder.

Signed-off-by: Andy Shevchenko <[email protected]>
Signed-off-by: Rafael J. Wysock

ACPI: x86: Move LPSS to x86 folder

LPSS is built solely for x86, move it to the respective folder.

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

show more ...

ACPI: x86: Move blacklist to x86 folder

blacklist is built solely for x86, move it to the respective folder.

Signed-off-by: Andy Shevchenko <[email protected]>
Signed-off-by: Rafael

ACPI: x86: Move blacklist to x86 folder

blacklist is built solely for x86, move it to the respective folder.

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

show more ...

ACPI: x86: Move acpi_cmos_rtc to x86 folder

acpi_cmos_rtc is built solely for x86, move it to the respective folder.

Signed-off-by: Andy Shevchenko <[email protected]>
Signed-off-by

ACPI: x86: Move acpi_cmos_rtc to x86 folder

acpi_cmos_rtc is built solely for x86, move it to the respective folder.

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

show more ...

ACPI: x86: Introduce a Makefile

There will be more modules coming here, so, introduce a separate
Makefile and include it in parent one via obj-$(CONFIG_X86).

Signed-off-by: Andy Shevchenko <andriy.

ACPI: x86: Introduce a Makefile

There will be more modules coming here, so, introduce a separate
Makefile and include it in parent one via obj-$(CONFIG_X86).

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

show more ...

ACPI: NHLT: Introduce API for the table

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

ACPI: NHLT: Introduce API for the table

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

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

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

show more ...

ACPI: Drop the custom_method debugfs interface

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

Moreover, the recipe for preparing a customi

ACPI: Drop the custom_method debugfs interface

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

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

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

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

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

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

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

show more ...

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

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

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

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

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

No intentional functional impact.

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

show more ...

ACPI: scan: Extract CSI-2 connection graph from _CRS

Find ACPI CSI-2 resource descriptors defined since ACPI 6.4 (for
CSI-2 and camera configuration) in _CRS for all device objects in
the given scop

ACPI: scan: Extract CSI-2 connection graph from _CRS

Find ACPI CSI-2 resource descriptors defined since ACPI 6.4 (for
CSI-2 and camera configuration) in _CRS for all device objects in
the given scope of the ACPI namespace that have them, identify the
corresponding "remote endpoint" device objects for them and
allocate memory for software nodes needed to create a DT-like data
structure representing the CSI-2 connection graph for drivers.

The code needed to populate these software nodes will be added by
subsequent change sets.

Link: https://uefi.org/specs/ACPI/6.5/06_Device_Configuration.html#camera-serial-interface-csi-2-connection-resource-descriptor
Co-developed-by: Sakari Ailus <[email protected]>
Signed-off-by: Sakari Ailus <[email protected]>
Signed-off-by: Rafael J. Wysocki <[email protected]>
Tested-by: Sakari Ailus <[email protected]>

show more ...

ACPI: Move AMBA bus scan handling into arm64 specific directory

Commit fcea0ccf4fd7 ("ACPI: bus: Consolidate all arm specific
initialisation into acpi_arm_init()") moved all of the ARM-specific
init

ACPI: Move AMBA bus scan handling into arm64 specific directory

Commit fcea0ccf4fd7 ("ACPI: bus: Consolidate all arm specific
initialisation into acpi_arm_init()") moved all of the ARM-specific
initialization into acpi_arm_init(). However, acpi_amba.c being outside
of drivers/acpi/arm64 got ignored and hence acpi_amba_init() was not
moved into acpi_arm_init().

Move the AMBA platform bus support into arm64 specific folder and make
acpi_amba_init() part of acpi_arm_init().

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

show more ...

drivers/acpi: RISC-V: Add RHCT related code

RHCT is a new table defined for RISC-V to communicate the
features of the CPU to the OS. Create a new architecture folder
in drivers/acpi and add RHCT par

drivers/acpi: RISC-V: Add RHCT related code

RHCT is a new table defined for RISC-V to communicate the
features of the CPU to the OS. Create a new architecture folder
in drivers/acpi and add RHCT parsing code.

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

show more ...

ACPI: Implement a generic FFH Opregion handler

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

ACPI: Implement a generic FFH Opregion handler

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

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

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

show more ...

ACPI: processor: Split out thermal initialization from ACPI PSS

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

ACPI: processor: Split out thermal initialization from ACPI PSS

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

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

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

show more ...

ACPI: fan: Separate file for attributes creation

Move the functionality of creation of sysfs attributes under acpi device
to a new file fan_attr.c. This cleans up the core fan code, which just
use t

ACPI: fan: Separate file for attributes creation

Move the functionality of creation of sysfs attributes under acpi device
to a new file fan_attr.c. This cleans up the core fan code, which just
use thermal sysfs interface. The original fan.c is renamed to
fan_core.c.

No functional changes are expected.

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

show more ...

kbuild: do not quote string values in include/config/auto.conf

The previous commit fixed up all shell scripts to not include
include/config/auto.conf.

Now that include/config/auto.conf is only incl

kbuild: do not quote string values in include/config/auto.conf

The previous commit fixed up all shell scripts to not include
include/config/auto.conf.

Now that include/config/auto.conf is only included by Makefiles,
we can change it into a more Make-friendly form.

Previously, Kconfig output string values enclosed with double-quotes
(both in the .config and include/config/auto.conf):

CONFIG_X="foo bar"

Unlike shell, Make handles double-quotes (and single-quotes as well)
verbatim. We must rip them off when used.

There are some patterns:

[1] $(patsubst "%",%,$(CONFIG_X))
[2] $(CONFIG_X:"%"=%)
[3] $(subst ",,$(CONFIG_X))
[4] $(shell echo $(CONFIG_X))

These are not only ugly, but also fragile.

[1] and [2] do not work if the value contains spaces, like
CONFIG_X=" foo bar "

[3] does not work correctly if the value contains double-quotes like
CONFIG_X="foo\"bar"

[4] seems to work better, but has a cost of forking a process.

Anyway, quoted strings were always PITA for our Makefiles.

This commit changes Kconfig to stop quoting in include/config/auto.conf.

These are the string type symbols referenced in Makefiles or scripts:

ACPI_CUSTOM_DSDT_FILE
ARC_BUILTIN_DTB_NAME
ARC_TUNE_MCPU
BUILTIN_DTB_SOURCE
CC_IMPLICIT_FALLTHROUGH
CC_VERSION_TEXT
CFG80211_EXTRA_REGDB_KEYDIR
EXTRA_FIRMWARE
EXTRA_FIRMWARE_DIR
EXTRA_TARGETS
H8300_BUILTIN_DTB
INITRAMFS_SOURCE
LOCALVERSION
MODULE_SIG_HASH
MODULE_SIG_KEY
NDS32_BUILTIN_DTB
NIOS2_DTB_SOURCE
OPENRISC_BUILTIN_DTB
SOC_CANAAN_K210_DTB_SOURCE
SYSTEM_BLACKLIST_HASH_LIST
SYSTEM_REVOCATION_KEYS
SYSTEM_TRUSTED_KEYS
TARGET_CPU
UNUSED_KSYMS_WHITELIST
XILINX_MICROBLAZE0_FAMILY
XILINX_MICROBLAZE0_HW_VER
XTENSA_VARIANT_NAME

I checked them one by one, and fixed up the code where necessary.

Signed-off-by: Masahiro Yamada <[email protected]>

show more ...

ACPI: PCC: Implement OperationRegion handler for the PCC Type 3 subtype

PCC OpRegion provides a mechanism to communicate with the platform
directly from the AML. PCCT provides the list of PCC channe

ACPI: PCC: Implement OperationRegion handler for the PCC Type 3 subtype

PCC OpRegion provides a mechanism to communicate with the platform
directly from the AML. PCCT provides the list of PCC channel available
in the platform, a subset or all of them can be used in PCC Opregion.

This patch registers the PCC OpRegion handler before ACPI tables are
loaded. This relies on the special context data passed to identify and
set up the PCC channel before the OpRegion handler is executed for the
first time.

Typical PCC Opregion declaration looks like this:

OperationRegion (PFRM, PCC, 2, 0x74)
Field (PFRM, ByteAcc, NoLock, Preserve)
{
SIGN, 32,
FLGS, 32,
LEN, 32,
CMD, 32,
DATA, 800
}

It contains four named double words followed by 100 bytes of buffer
names DATA.

ASL can fill out the buffer something like:

/* Create global or local buffer */
Name (BUFF, Buffer (0x0C){})
/* Create double word fields over the buffer */
CreateDWordField (BUFF, 0x0, WD0)
CreateDWordField (BUFF, 0x04, WD1)
CreateDWordField (BUFF, 0x08, WD2)

/* Fill the named fields */
WD0 = 0x50434300
SIGN = BUFF
WD0 = 1
FLGS = BUFF
WD0 = 0x10
LEN = BUFF

/* Fill the payload in the DATA buffer */
WD0 = 0
WD1 = 0x08
WD2 = 0
DATA = BUFF

/* Write to CMD field to trigger handler */
WD0 = 0x4404
CMD = BUFF

This buffer is received by acpi_pcc_opregion_space_handler. This
handler will fetch the complete buffer via internal_pcc_buffer.

The setup handler will receive the special PCC context data which will
contain the PCC channel index which used to set up the channel. The
buffer pointer and length is saved in region context which is then used
in the handler.

(kernel test robot: Build failure with CONFIG_ACPI_DEBUGGER)
Link: https://lore.kernel.org/r/[email protected]
Reported-by: kernel test robot <[email protected]>
Signed-off-by: Sudeep Holla <[email protected]>
Signed-off-by: Rafael J. Wysocki <[email protected]>

show more ...

ACPI: Introduce Platform Firmware Runtime Telemetry driver

This driver allows user space to fetch telemetry data from the
firmware with the help of the Platform Firmware Runtime Telemetry
interface.

ACPI: Introduce Platform Firmware Runtime Telemetry driver

This driver allows user space to fetch telemetry data from the
firmware with the help of the Platform Firmware Runtime Telemetry
interface.

Both PFRU and PFRT are based on ACPI _DSM interfaces located under
special device objects in the ACPI Namespace, but these interfaces
are different from each other, so it is better to provide a separate
driver from each of them, even though they share some common
definitions and naming conventions.

Tested-by: Hongyu Ning <[email protected]>
Signed-off-by: Chen Yu <[email protected]>
[ rjw: Subject and changelog edits ]
Signed-off-by: Rafael J. Wysocki <[email protected]>

show more ...

ACPI: Introduce Platform Firmware Runtime Update device driver

Introduce the pfr_update driver which can be used for Platform Firmware
Runtime code injection and driver update [1].

The user is expe

ACPI: Introduce Platform Firmware Runtime Update device driver

Introduce the pfr_update driver which can be used for Platform Firmware
Runtime code injection and driver update [1].

The user is expected to provide the EFI capsule, and pass it to the
driver by writing the capsule to a device special file. The capsule
is transferred by the driver to the platform firmware with the help
of an ACPI _DSM method under the special ACPI Platform Firmware
Runtime Update device (INTC1080), and the actual firmware update is
carried out by the low-level Management Mode code in the platform
firmware.

This change allows certain pieces of the platform firmware to be
updated on the fly while the system is running (runtime) without the
need to restart it, which is key in the cases when the system needs to
be available 100% of the time and it cannot afford the downtime related
to restarting it, or when the work carried out by the system is
particularly important, so it cannot be interrupted, and it is not
practical to wait until it is complete.

Link: https://uefi.org/sites/default/files/resources/Intel_MM_OS_Interface_Spec_Rev100.pdf # [1]
Tested-by: Hongyu Ning <[email protected]>
Signed-off-by: Chen Yu <[email protected]>
[ rjw: Subject and changelog edits ]
Signed-off-by: Rafael J. Wysocki <[email protected]>

show more ...

ACPI: Add driver for the VIOT table

The ACPI Virtual I/O Translation Table describes topology of
para-virtual platforms, similarly to vendor tables DMAR, IVRS and IORT.
For now it describes the rela

ACPI: Add driver for the VIOT table

The ACPI Virtual I/O Translation Table describes topology of
para-virtual platforms, similarly to vendor tables DMAR, IVRS and IORT.
For now it describes the relation between virtio-iommu and the endpoints
it manages.

Three steps are needed to configure DMA of endpoints:

(1) acpi_viot_init(): parse the VIOT table, find or create the fwnode
associated to each vIOMMU device. This needs to happen after
acpi_scan_init(), because it relies on the struct device and their
fwnode to be available.

(2) When probing the vIOMMU device, the driver registers its IOMMU ops
within the IOMMU subsystem. This step doesn't require any
intervention from the VIOT driver.

(3) viot_iommu_configure(): before binding the endpoint to a driver,
find the associated IOMMU ops. Register them, along with the
endpoint ID, into the device's iommu_fwspec.

If step (3) happens before step (2), it is deferred until the IOMMU is
initialized, then retried.

Tested-by: Eric Auger <[email protected]>
Reviewed-by: Eric Auger <[email protected]>
Signed-off-by: Jean-Philippe Brucker <[email protected]>
Acked-by: Rafael J. Wysocki <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Joerg Roedel <[email protected]>

show more ...

ACPI: tables: Add custom DSDT file as makefile prerequisite

A custom DSDT file is mostly used during development or debugging,
and in that case it is quite likely to want to rebuild the kernel
after

ACPI: tables: Add custom DSDT file as makefile prerequisite

A custom DSDT file is mostly used during development or debugging,
and in that case it is quite likely to want to rebuild the kernel
after changing ONLY the content of the DSDT.

This patch adds the custom DSDT as a prerequisite to tables.o
to ensure a rebuild if the DSDT file is updated. Make will merge
the prerequisites from multiple rules for the same target.

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

show more ...

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

ACPI: tables: introduce support for FPDT table

ACPI Firmware Performance Data Table (FPDT) provides information about
firmware performance during system boot, S3 suspend and S3 resume.

Have the ker

ACPI: tables: introduce support for FPDT table

ACPI Firmware Performance Data Table (FPDT) provides information about
firmware performance during system boot, S3 suspend and S3 resume.

Have the kernel parse the FPDT table, and expose the firmware
performance data to userspace as sysfs attributes under
/sys/firmware/acpi/fpdt/.

Tested-by: Todd Brandt <[email protected]>
Signed-off-by: Zhang Rui <[email protected]>
Signed-off-by: Rafael J. Wysocki <[email protected]>

show more ...

ACPI: platform: Add platform profile support

This is the initial implementation of the platform-profile feature.
It provides the details discussed and outlined in the
sysfs-platform_profile document

ACPI: platform: Add platform profile support

This is the initial implementation of the platform-profile feature.
It provides the details discussed and outlined in the
sysfs-platform_profile document.

Many modern systems have the ability to modify the operating profile to
control aspects like fan speed, temperature and power levels. This
module provides a common sysfs interface that platform modules can register
against to control their individual profile options.

Signed-off-by: Mark Pearson <[email protected]>
Reviewed-by: Hans de Goede <[email protected]>
[ rjw: Use full words in enum values names ]
Signed-off-by: Rafael J. Wysocki <[email protected]>

show more ...