License cleanup: add SPDX GPL-2.0 license identifier to files with no license
Many source files in the tree are missing licensing information, which
makes it harder for compliance tools to determine the correct license.
By default all files without license information are under the default
license of the kernel, which is GPL version 2.
Update the files which contain no license information with the 'GPL-2.0'
SPDX license identifier. The SPDX identifier is a legally binding
shorthand, which can be used instead of the full boiler plate text.
This patch is based on work done by Thomas Gleixner and Kate Stewart and
Philippe Ombredanne.
How this work was done:
Patches were generated and checked against linux-4.14-rc6 for a subset of
the use cases:
- file had no licensing information it it.
- file was a */uapi/* one with no licensing information in it,
- file was a */uapi/* one with existing licensing information,
Further patches will be generated in subsequent months to fix up cases
where non-standard license headers were used, and references to license
had to be inferred by heuristics based on keywords.
The analysis to determine which SPDX License Identifier to be applied to
a file was done in a spreadsheet of side by side results from of the
output of two independent scanners (ScanCode & Windriver) producing SPDX
tag:value files created by Philippe Ombredanne. Philippe prepared the
base worksheet, and did an initial spot review of a few 1000 files.
The 4.13 kernel was the starting point of the analysis with 60,537 files
assessed. Kate Stewart did a file by file comparison of the scanner
results in the spreadsheet to determine which SPDX license identifier(s)
to be applied to the file. She confirmed any determination that was not
immediately clear with lawyers working with the Linux Foundation.
Criteria used to select files for SPDX license identifier tagging was:
- Files considered eligible had to be source code files.
- Make and config files were included as candidates if they contained >5
lines of source
- File already had some variant of a license header in it (even if <5
lines).
All documentation files were explicitly excluded.
The following heuristics were used to determine which SPDX license
identifiers to apply.
- when both scanners couldn't find any license traces, file was
considered to have no license information in it, and the top level
COPYING file license applied.
For non */uapi/* files that summary was:
SPDX license identifier # files
---------------------------------------------------|-------
GPL-2.0 11139
and resulted in the first patch in this series.
If that file was a */uapi/* path one, it was "GPL-2.0 WITH
Linux-syscall-note" otherwise it was "GPL-2.0". Results of that was:
SPDX license identifier # files
---------------------------------------------------|-------
GPL-2.0 WITH Linux-syscall-note 930
and resulted in the second patch in this series.
- if a file had some form of licensing information in it, and was one
of the */uapi/* ones, it was denoted with the Linux-syscall-note if
any GPL family license was found in the file or had no licensing in
it (per prior point). Results summary:
SPDX license identifier # files
---------------------------------------------------|------
GPL-2.0 WITH Linux-syscall-note 270
GPL-2.0+ WITH Linux-syscall-note 169
((GPL-2.0 WITH Linux-syscall-note) OR BSD-2-Clause) 21
((GPL-2.0 WITH Linux-syscall-note) OR BSD-3-Clause) 17
LGPL-2.1+ WITH Linux-syscall-note 15
GPL-1.0+ WITH Linux-syscall-note 14
((GPL-2.0+ WITH Linux-syscall-note) OR BSD-3-Clause) 5
LGPL-2.0+ WITH Linux-syscall-note 4
LGPL-2.1 WITH Linux-syscall-note 3
((GPL-2.0 WITH Linux-syscall-note) OR MIT) 3
((GPL-2.0 WITH Linux-syscall-note) AND MIT) 1
and that resulted in the third patch in this series.
- when the two scanners agreed on the detected license(s), that became
the concluded license(s).
- when there was disagreement between the two scanners (one detected a
license but the other didn't, or they both detected different
licenses) a manual inspection of the file occurred.
- In most cases a manual inspection of the information in the file
resulted in a clear resolution of the license that should apply (and
which scanner probably needed to revisit its heuristics).
- When it was not immediately clear, the license identifier was
confirmed with lawyers working with the Linux Foundation.
- If there was any question as to the appropriate license identifier,
the file was flagged for further research and to be revisited later
in time.
In total, over 70 hours of logged manual review was done on the
spreadsheet to determine the SPDX license identifiers to apply to the
source files by Kate, Philippe, Thomas and, in some cases, confirmation
by lawyers working with the Linux Foundation.
Kate also obtained a third independent scan of the 4.13 code base from
FOSSology, and compared selected files where the other two scanners
disagreed against that SPDX file, to see if there was new insights. The
Windriver scanner is based on an older version of FOSSology in part, so
they are related.
Thomas did random spot checks in about 500 files from the spreadsheets
for the uapi headers and agreed with SPDX license identifier in the
files he inspected. For the non-uapi files Thomas did random spot checks
in about 15000 files.
In initial set of patches against 4.14-rc6, 3 files were found to have
copy/paste license identifier errors, and have been fixed to reflect the
correct identifier.
Additionally Philippe spent 10 hours this week doing a detailed manual
inspection and review of the 12,461 patched files from the initial patch
version early this week with:
- a full scancode scan run, collecting the matched texts, detected
license ids and scores
- reviewing anything where there was a license detected (about 500+
files) to ensure that the applied SPDX license was correct
- reviewing anything where there was no detection but the patch license
was not GPL-2.0 WITH Linux-syscall-note to ensure that the applied
SPDX license was correct
This produced a worksheet with 20 files needing minor correction. This
worksheet was then exported into 3 different .csv files for the
different types of files to be modified.
These .csv files were then reviewed by Greg. Thomas wrote a script to
parse the csv files and add the proper SPDX tag to the file, in the
format that the file expected. This script was further refined by Greg
based on the output to detect more types of files automatically and to
distinguish between header and source .c files (which need different
comment types.) Finally Greg ran the script using the .csv files to
generate the patches.
Reviewed-by: Kate Stewart <kstewart@linuxfoundation.org>
Reviewed-by: Philippe Ombredanne <pombredanne@nexb.com>
Reviewed-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-11-01 14:07:57 +00:00
|
|
|
# SPDX-License-Identifier: GPL-2.0
|
2005-04-16 22:20:36 +00:00
|
|
|
#
|
|
|
|
|
# Makefile for the Linux ACPI interpreter
|
2007-03-07 19:28:00 +00:00
|
|
|
#
|
2005-04-16 22:20:36 +00:00
|
|
|
|
2009-01-09 05:13:17 +00:00
|
|
|
ccflags-$(CONFIG_ACPI_DEBUG) += -DACPI_DEBUG_OUTPUT
|
2005-04-16 22:20:36 +00:00
|
|
|
|
|
|
|
|
#
|
|
|
|
|
# ACPI Boot-Time Table Parsing
|
|
|
|
|
#
|
2021-06-21 15:24:33 +00:00
|
|
|
ifeq ($(CONFIG_ACPI_CUSTOM_DSDT),y)
|
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 <masahiroy@kernel.org>
2021-12-14 02:53:53 +00:00
|
|
|
tables.o: $(src)/../../include/$(CONFIG_ACPI_CUSTOM_DSDT_FILE) ;
|
2021-06-21 15:24:33 +00:00
|
|
|
|
|
|
|
|
endif
|
|
|
|
|
|
2015-11-20 17:35:02 +00:00
|
|
|
obj-$(CONFIG_ACPI) += tables.o
|
2005-09-22 05:15:57 +00:00
|
|
|
obj-$(CONFIG_X86) += blacklist.o
|
2005-04-16 22:20:36 +00:00
|
|
|
|
|
|
|
|
#
|
|
|
|
|
# ACPI Core Subsystem (Interpreter)
|
|
|
|
|
#
|
2015-11-20 17:35:02 +00:00
|
|
|
obj-$(CONFIG_ACPI) += acpi.o \
|
2009-01-09 05:13:17 +00:00
|
|
|
acpica/
|
|
|
|
|
|
2009-03-11 22:37:19 +00:00
|
|
|
# All the builtin files are in the "acpi." module_param namespace.
|
2016-05-03 08:49:01 +00:00
|
|
|
acpi-y += osi.o osl.o utils.o reboot.o
|
2011-12-08 03:25:49 +00:00
|
|
|
acpi-y += nvs.o
|
2009-03-11 22:37:19 +00:00
|
|
|
|
2012-11-02 00:40:09 +00:00
|
|
|
# Power management related files
|
2009-03-11 22:37:19 +00:00
|
|
|
acpi-y += wakeup.o
|
2015-03-24 14:02:39 +00:00
|
|
|
acpi-$(CONFIG_ACPI_SYSTEM_POWER_STATES_SUPPORT) += sleep.o
|
2015-07-17 20:53:43 +00:00
|
|
|
acpi-y += device_sysfs.o device_pm.o
|
2011-12-08 03:25:49 +00:00
|
|
|
acpi-$(CONFIG_ACPI_SLEEP) += proc.o
|
2009-01-09 05:13:17 +00:00
|
|
|
|
2005-04-16 22:20:36 +00:00
|
|
|
|
|
|
|
|
#
|
|
|
|
|
# ACPI Bus and Device Drivers
|
|
|
|
|
#
|
2009-03-11 22:37:19 +00:00
|
|
|
acpi-y += bus.o glue.o
|
|
|
|
|
acpi-y += scan.o
|
2012-11-14 23:30:01 +00:00
|
|
|
acpi-y += resource.o
|
ACPI / processor: Use common hotplug infrastructure
Split the ACPI processor driver into two parts, one that is
non-modular, resides in the ACPI core and handles the enumeration
and hotplug of processors and one that implements the rest of the
existing processor driver functionality.
The non-modular part uses an ACPI scan handler object to enumerate
processors on the basis of information provided by the ACPI namespace
and to hook up with the common ACPI hotplug infrastructure. It also
populates the ACPI handle of each processor device having a
corresponding object in the ACPI namespace, which allows the driver
proper to bind to those devices, and makes the driver bind to them
if it is readily available (i.e. loaded) when the scan handler's
.attach() routine is running.
There are a few reasons to make this change.
First, switching the ACPI processor driver to using the common ACPI
hotplug infrastructure reduces code duplication and size considerably,
even though a new file is created along with a header comment etc.
Second, since the common hotplug code attempts to offline devices
before starting the (non-reversible) removal procedure, it will abort
(and possibly roll back) hot-remove operations involving processors
if cpu_down() returns an error code for one of them instead of
continuing them blindly (if /sys/firmware/acpi/hotplug/force_remove
is unset). That is a more desirable behavior than what the current
code does.
Finally, the separation of the scan/hotplug part from the driver
proper makes it possible to simplify the driver's .remove() routine,
because it doesn't need to worry about the possible cleanup related
to processor removal any more (the scan/hotplug part is responsible
for that now) and can handle device removal and driver removal
symmetricaly (i.e. as appropriate).
Some user-visible changes in sysfs are made (for example, the
'sysdev' link from the ACPI device node to the processor device's
directory is gone and a 'physical_node' link is present instead
and a corresponding 'firmware_node' is present in the processor
device's directory, the processor driver is now visible under
/sys/bus/cpu/drivers/ and bound to the processor device), but
that shouldn't affect the functionality that users care about
(frequency scaling, C-states and thermal management).
Tested on my venerable Toshiba Portege R500.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Reviewed-by: Toshi Kani <toshi.kani@hp.com>
2013-05-02 22:26:22 +00:00
|
|
|
acpi-y += acpi_processor.o
|
2010-02-22 19:11:14 +00:00
|
|
|
acpi-y += processor_core.o
|
2014-07-18 10:02:54 +00:00
|
|
|
acpi-$(CONFIG_ARCH_MIGHT_HAVE_ACPI_PDC) += processor_pdc.o
|
2009-03-11 22:37:19 +00:00
|
|
|
acpi-y += ec.o
|
|
|
|
|
acpi-$(CONFIG_ACPI_DOCK) += dock.o
|
2018-12-19 22:46:56 +00:00
|
|
|
acpi-$(CONFIG_PCI) += pci_root.o pci_link.o pci_irq.o
|
2016-06-10 19:55:13 +00:00
|
|
|
obj-$(CONFIG_ACPI_MCFG) += pci_mcfg.o
|
2019-01-05 10:05:56 +00:00
|
|
|
acpi-$(CONFIG_PCI) += acpi_lpss.o
|
|
|
|
|
acpi-y += acpi_apd.o
|
2012-10-31 21:45:02 +00:00
|
|
|
acpi-y += acpi_platform.o
|
ACPI / PNP: use device ID list for PNPACPI device enumeration
ACPI can be used to enumerate PNP devices, but the code does not
handle this in the right way currently. Namely, if an ACPI device
object
1. Has a _CRS method,
2. Has an identification of
"three capital characters followed by four hex digits",
3. Is not in the excluded IDs list,
it will be enumerated to PNP bus (that is, a PNP device object will
be create for it). This means that, actually, the PNP bus type is
used as the default bus type for enumerating _HID devices in ACPI.
However, more and more _HID devices need to be enumerated to the
platform bus instead (that is, platform device objects need to be
created for them). As a result, the device ID list in acpi_platform.c
is used to enforce creating platform device objects rather than PNP
device objects for matching devices. That list has been continuously
growing recently, unfortunately, and it is pretty much guaranteed to
grow even more in the future.
To address that problem it is better to enumerate _HID devices
as platform devices by default. To this end, change the way of
enumerating PNP devices by adding a PNP ACPI scan handler that
will use a device ID list to create PNP devices for the ACPI
device objects whose device IDs are present in that list.
The initial device ID list in the PNP ACPI scan handler contains
all of the pnp_device_id strings from all the existing PNP drivers,
so this change should be transparent to the PNP core and all of the
PNP drivers. Still, in the future it should be possible to reduce
its size by converting PNP drivers that need not be PNP for any
technical reasons into platform drivers.
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
[rjw: Rewrote the changelog, modified the PNP ACPI scan handler code]
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2014-05-30 02:23:01 +00:00
|
|
|
acpi-y += acpi_pnp.o
|
2016-01-20 14:29:27 +00:00
|
|
|
acpi-$(CONFIG_ARM_AMBA) += acpi_amba.o
|
2009-03-11 22:37:19 +00:00
|
|
|
acpi-y += power.o
|
2010-07-15 02:46:33 +00:00
|
|
|
acpi-y += event.o
|
2019-10-09 13:04:33 +00:00
|
|
|
acpi-y += evged.o
|
2010-07-15 02:46:30 +00:00
|
|
|
acpi-y += sysfs.o
|
ACPI: Add support for device specific properties
Device Tree is used in many embedded systems to describe the system
configuration to the OS. It supports attaching properties or name-value
pairs to the devices it describe. With these properties one can pass
additional information to the drivers that would not be available
otherwise.
ACPI is another configuration mechanism (among other things) typically
seen, but not limited to, x86 machines. ACPI allows passing arbitrary
data from methods but there has not been mechanism equivalent to Device
Tree until the introduction of _DSD in the recent publication of the
ACPI 5.1 specification.
In order to facilitate ACPI usage in systems where Device Tree is
typically used, it would be beneficial to standardize a way to retrieve
Device Tree style properties from ACPI devices, which is what we do in
this patch.
If a given device described in ACPI namespace wants to export properties it
must implement _DSD method (Device Specific Data, introduced with ACPI 5.1)
that returns the properties in a package of packages. For example:
Name (_DSD, Package () {
ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
Package () {
Package () {"name1", <VALUE1>},
Package () {"name2", <VALUE2>},
...
}
})
The UUID reserved for properties is daffd814-6eba-4d8c-8a91-bc9bbf4aa301
and is documented in the ACPI 5.1 companion document called "_DSD
Implementation Guide" [1], [2].
We add several helper functions that can be used to extract these
properties and convert them to different Linux data types.
The ultimate goal is that we only have one device property API that
retrieves the requested properties from Device Tree or from ACPI
transparent to the caller.
[1] http://www.uefi.org/sites/default/files/resources/_DSD-implementation-guide-toplevel.htm
[2] http://www.uefi.org/sites/default/files/resources/_DSD-device-properties-UUID.pdf
Reviewed-by: Hanjun Guo <hanjun.guo@linaro.org>
Reviewed-by: Josh Triplett <josh@joshtriplett.org>
Reviewed-by: Grant Likely <grant.likely@linaro.org>
Signed-off-by: Darren Hart <dvhart@linux.intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-10-21 11:33:55 +00:00
|
|
|
acpi-y += property.o
|
2013-06-05 02:27:50 +00:00
|
|
|
acpi-$(CONFIG_X86) += acpi_cmos_rtc.o
|
ACPI / property: Support Apple _DSM properties
While the rest of the world has standardized on _DSD as the way to store
device properties in AML (introduced with ACPI 5.1 in 2014), Apple has
been using a custom _DSM to achieve the same for much longer (ever since
they switched from DeviceTree-based PowerPC to Intel in 2005, verified
with MacOS X 10.4.11).
The theory of operation on macOS is as follows: AppleACPIPlatform.kext
invokes mergeEFIproperties() and mergeDSMproperties() for each device to
merge properties conveyed by EFI drivers as well as properties stored in
AML into the I/O Kit registry from which they can be retrieved by
drivers. We've been supporting EFI properties since commit 58c5475aba67
("x86/efi: Retrieve and assign Apple device properties"). The present
commit adds support for _DSM properties, thereby completing our support
for Apple device properties. The _DSM properties are made available
under the primary fwnode, the EFI properties under the secondary fwnode.
So for devices which possess both property types, they can all be
elegantly accessed with the uniform API in <linux/property.h>.
Until recently we had no need to support _DSM properties, they contained
only uninteresting garbage. The situation has changed with MacBooks and
MacBook Pros introduced since 2015: Their keyboard is attached with SPI
instead of USB and the _CRS data which is necessary to initialize the
spi driver only contains valid information if OSPM responds "false" to
_OSI("Darwin"). If OSPM responds "true", _CRS is empty and the spi
driver fails to initialize. The rationale is very simple, Apple only
cares about macOS and Windows: On Windows, _CRS contains valid data,
whereas on macOS it is empty. Instead, macOS gleans the necessary data
from the _DSM properties.
Since Linux deliberately defaults to responding "true" to _OSI("Darwin"),
we need to emulate macOS' behaviour by initializing the spi driver with
data returned by the _DSM.
An out-of-tree driver for the SPI keyboard exists which currently binds
to the ACPI device, invokes the _DSM, parses the returned package and
instantiates an SPI device with the data gleaned from the _DSM:
https://github.com/cb22/macbook12-spi-driver/commit/9a416d699ef4
https://github.com/cb22/macbook12-spi-driver/commit/0c34936ed9a1
By adding support for Apple's _DSM properties in generic ACPI code, the
out-of-tree driver will be able to register as a regular SPI driver,
significantly reducing its amount of code and improving its chances to
be mainlined.
The SPI keyboard will not be the only user of this commit: E.g. on the
MacBook8,1, the UART-attached Bluetooth device likewise returns empty
_CRS data if OSPM returns "true" to _OSI("Darwin").
The _DSM returns a Package whose format unfortunately deviates slightly
from the _DSD spec: The properties are marshalled up in a single Package
as alternating key/value elements, unlike _DSD which stores them as a
Package of 2-element Packages. The present commit therefore converts
the Package to _DSD format and the ACPI core can then treat the data as
if Apple would follow the standard.
Well, except for one small annoyance: The properties returned by the
_DSM only ever have one of two types, Integer or Buffer. The former is
retrievable as usual with device_property_read_u64(), but the latter is
not part of the _DSD spec and it is not possible to retrieve Buffer
properties with the device_property_read_*() functions due to the type
checking performed in drivers/acpi/property.c. It is however possible
to retrieve them with acpi_dev_get_property(). Apple is using the
Buffer type somewhat sloppily to store null-terminated strings but also
integers. The real data type is not distinguishable by the ACPI core
and the onus is on the caller to use the contents of the Buffer in an
appropriate way.
In case Apple moves to _DSD in the future, this commit first checks for
_DSD and falls back to _DSM only if _DSD is not found.
Tested-by: Ronald Tschalär <ronald@innovation.ch>
Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Lukas Wunner <lukas@wunner.de>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-08-01 12:10:41 +00:00
|
|
|
acpi-$(CONFIG_X86) += x86/apple.o
|
2017-04-21 10:47:40 +00:00
|
|
|
acpi-$(CONFIG_X86) += x86/utils.o
|
2020-12-17 19:23:17 +00:00
|
|
|
acpi-$(CONFIG_X86) += x86/s2idle.o
|
2010-07-15 02:46:15 +00:00
|
|
|
acpi-$(CONFIG_DEBUG_FS) += debugfs.o
|
2015-01-28 19:56:46 +00:00
|
|
|
acpi-y += acpi_lpat.o
|
2021-01-29 06:15:48 +00:00
|
|
|
acpi-$(CONFIG_ACPI_FPDT) += acpi_fpdt.o
|
2017-10-05 23:24:03 +00:00
|
|
|
acpi-$(CONFIG_ACPI_LPIT) += acpi_lpit.o
|
2017-02-02 23:23:58 +00:00
|
|
|
acpi-$(CONFIG_ACPI_GENERIC_GSI) += irq.o
|
2016-09-20 12:30:51 +00:00
|
|
|
acpi-$(CONFIG_ACPI_WATCHDOG) += acpi_watchdog.o
|
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 <erik.kaneda@intel.com>
[ rjw: Subject and changelog edits ]
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2021-06-10 03:41:52 +00:00
|
|
|
acpi-$(CONFIG_ACPI_PRMT) += prmt.o
|
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/202201041539.feAV0l27-lkp@intel.com
Reported-by: kernel test robot <lkp@intel.com>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2022-01-04 19:51:08 +00:00
|
|
|
acpi-$(CONFIG_ACPI_PCC) += acpi_pcc.o
|
2005-04-16 22:20:36 +00:00
|
|
|
|
2018-10-15 23:11:31 +00:00
|
|
|
# Address translation
|
|
|
|
|
acpi-$(CONFIG_ACPI_ADXL) += acpi_adxl.o
|
|
|
|
|
|
2009-03-11 22:37:19 +00:00
|
|
|
# These are (potentially) separate modules
|
2012-10-16 20:53:37 +00:00
|
|
|
|
|
|
|
|
# IPMI may be used by other drivers, so it has to initialise before them
|
|
|
|
|
obj-$(CONFIG_ACPI_IPMI) += acpi_ipmi.o
|
|
|
|
|
|
2005-04-16 22:20:36 +00:00
|
|
|
obj-$(CONFIG_ACPI_AC) += ac.o
|
|
|
|
|
obj-$(CONFIG_ACPI_BUTTON) += button.o
|
2020-02-11 23:38:06 +00:00
|
|
|
obj-$(CONFIG_ACPI_TINY_POWER_BUTTON) += tiny-power-button.o
|
2005-04-16 22:20:36 +00:00
|
|
|
obj-$(CONFIG_ACPI_FAN) += fan.o
|
2006-10-20 21:30:25 +00:00
|
|
|
obj-$(CONFIG_ACPI_VIDEO) += video.o
|
2018-03-16 12:51:01 +00:00
|
|
|
obj-$(CONFIG_ACPI_TAD) += acpi_tad.o
|
2008-06-10 21:30:42 +00:00
|
|
|
obj-$(CONFIG_ACPI_PCI_SLOT) += pci_slot.o
|
2005-04-16 22:20:36 +00:00
|
|
|
obj-$(CONFIG_ACPI_PROCESSOR) += processor.o
|
2015-11-20 17:35:02 +00:00
|
|
|
obj-$(CONFIG_ACPI) += container.o
|
2005-04-16 22:20:36 +00:00
|
|
|
obj-$(CONFIG_ACPI_THERMAL) += thermal.o
|
2020-12-30 00:18:26 +00:00
|
|
|
obj-$(CONFIG_ACPI_PLATFORM_PROFILE) += platform_profile.o
|
2016-07-24 04:24:19 +00:00
|
|
|
obj-$(CONFIG_ACPI_NFIT) += nfit/
|
2019-11-07 01:42:55 +00:00
|
|
|
obj-$(CONFIG_ACPI_NUMA) += numa/
|
2015-11-20 17:35:02 +00:00
|
|
|
obj-$(CONFIG_ACPI) += acpi_memhotplug.o
|
2015-02-05 05:44:49 +00:00
|
|
|
obj-$(CONFIG_ACPI_HOTPLUG_IOAPIC) += ioapic.o
|
2009-01-10 19:19:05 +00:00
|
|
|
obj-$(CONFIG_ACPI_BATTERY) += battery.o
|
2007-09-26 15:43:28 +00:00
|
|
|
obj-$(CONFIG_ACPI_SBS) += sbshc.o
|
2008-02-09 08:22:13 +00:00
|
|
|
obj-$(CONFIG_ACPI_SBS) += sbs.o
|
2010-05-18 06:35:17 +00:00
|
|
|
obj-$(CONFIG_ACPI_HED) += hed.o
|
2010-07-16 11:11:31 +00:00
|
|
|
obj-$(CONFIG_ACPI_EC_DEBUGFS) += ec_sys.o
|
2011-05-26 10:26:24 +00:00
|
|
|
obj-$(CONFIG_ACPI_CUSTOM_METHOD)+= custom_method.o
|
2012-01-31 18:19:20 +00:00
|
|
|
obj-$(CONFIG_ACPI_BGRT) += bgrt.o
|
2015-10-02 14:01:19 +00:00
|
|
|
obj-$(CONFIG_ACPI_CPPC_LIB) += cppc_acpi.o
|
2016-09-27 20:54:13 +00:00
|
|
|
obj-$(CONFIG_ACPI_SPCR_TABLE) += spcr.o
|
2015-12-03 02:43:14 +00:00
|
|
|
obj-$(CONFIG_ACPI_DEBUGGER_USER) += acpi_dbg.o
|
2018-05-11 23:58:01 +00:00
|
|
|
obj-$(CONFIG_ACPI_PPTT) += pptt.o
|
2021-12-22 04:32:02 +00:00
|
|
|
obj-$(CONFIG_ACPI_PFRUT) += pfr_update.o pfr_telemetry.o
|
2009-03-11 22:37:19 +00:00
|
|
|
|
2009-04-03 02:49:43 +00:00
|
|
|
# processor has its own "processor." module_param namespace
|
2015-08-05 13:40:26 +00:00
|
|
|
processor-y := processor_driver.o
|
|
|
|
|
processor-$(CONFIG_ACPI_PROCESSOR_IDLE) += processor_idle.o
|
2015-08-05 13:40:25 +00:00
|
|
|
processor-$(CONFIG_ACPI_CPU_FREQ_PSS) += processor_throttling.o \
|
|
|
|
|
processor_thermal.o
|
2009-04-03 02:49:43 +00:00
|
|
|
processor-$(CONFIG_CPU_FREQ) += processor_perflib.o
|
ACPI: create Processor Aggregator Device driver
ACPI 4.0 created the logical "processor aggregator device" as
a mechinism for platforms to ask the OS to force otherwise busy
processors to enter (power saving) idle.
The intent is to lower power consumption to ride-out
transient electrical and thermal emergencies,
rather than powering off the server.
On platforms that can save more power/performance via P-states,
the platform will first exhaust P-states before forcing idle.
However, the relative benefit of P-states vs. idle states
is platform dependent, and thus this driver need not know
or care about it.
This driver does not use the kernel's CPU hot-plug mechanism
because after the transient emergency is over, the system must
be returned to its normal state, and hotplug would permanently
break both cpusets and binding.
So to force idle, the driver creates a power saving thread.
The scheduler will migrate the thread to the preferred CPU.
The thread has max priority and has SCHED_RR policy,
so it can occupy one CPU. To save power, the thread will
invoke the deep C-state entry instructions.
To avoid starvation, the thread will sleep 5% of the time
time for every second (current RT scheduler has threshold
to avoid starvation, but if other CPUs are idle,
the CPU can borrow CPU timer from other,
which makes the mechanism not work here)
Vaidyanathan Srinivasan has proposed scheduler enhancements
to allow injecting idle time into the system. This driver doesn't
depend on those enhancements, but could cut over to them
when they are available.
Peter Z. does not favor upstreaming this driver until
the those scheduler enhancements are in place. However,
we favor upstreaming this driver now because it is useful
now, and can be enhanced over time.
Signed-off-by: Shaohua Li <shaohua.li@intel.com>
NACKed-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Vaidyanathan Srinivasan <svaidy@linux.vnet.ibm.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2009-07-27 22:11:02 +00:00
|
|
|
|
|
|
|
|
obj-$(CONFIG_ACPI_PROCESSOR_AGGREGATOR) += acpi_pad.o
|
2010-05-18 06:35:12 +00:00
|
|
|
|
|
|
|
|
obj-$(CONFIG_ACPI_APEI) += apei/
|
2013-10-21 21:29:25 +00:00
|
|
|
|
|
|
|
|
obj-$(CONFIG_ACPI_EXTLOG) += acpi_extlog.o
|
2014-11-24 09:21:54 +00:00
|
|
|
|
2016-07-11 13:13:36 +00:00
|
|
|
obj-$(CONFIG_ACPI_CONFIGFS) += acpi_configfs.o
|
2015-06-16 14:27:47 +00:00
|
|
|
|
2020-08-14 13:27:25 +00:00
|
|
|
obj-y += pmic/
|
2017-07-29 00:30:26 +00:00
|
|
|
|
2015-06-16 14:27:47 +00:00
|
|
|
video-objs += acpi_video.o video_detect.o
|
2016-07-17 20:45:32 +00:00
|
|
|
obj-y += dptf/
|
2016-09-12 18:54:20 +00:00
|
|
|
|
|
|
|
|
obj-$(CONFIG_ARM64) += arm64/
|
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 <eric.auger@redhat.com>
Reviewed-by: Eric Auger <eric.auger@redhat.com>
Signed-off-by: Jean-Philippe Brucker <jean-philippe@linaro.org>
Acked-by: Rafael J. Wysocki <rafael@kernel.org>
Link: https://lore.kernel.org/r/20210618152059.1194210-4-jean-philippe@linaro.org
Signed-off-by: Joerg Roedel <jroedel@suse.de>
2021-06-18 15:20:58 +00:00
|
|
|
|
|
|
|
|
obj-$(CONFIG_ACPI_VIOT) += viot.o
|
