| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
The ACPI _HRV object on the device is used to supply Linux with the
device's hardware revision. This is an optional object. Add sysfs support
for the _HRV object if it exists on the device.
This change allows users to easily find the hardware version of non-PCI
hardware by looking at the sysfs 'hrv' file. It is most useful for
non-PCI devices because lspci can list the hardware version for PCI
devices.
Signed-off-by: Betty Dall <betty.dall@hpe.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
The acpi_video_get_levels is useful for other drivers, i.e. the
to-be-added int3406 thermal driver, so export it.
Signed-off-by: Aaron Lu <aaron.lu@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
Since we will need the backlight_device_get_by_type API, we can use it
instead of the backlight_device_registered API whenever necessary so
remove the backlight_device_registered API.
Signed-off-by: Aaron Lu <aaron.lu@intel.com>
Acked-by: Jingoo Han <jg1.han@samsung.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
ACPICA commit 7a3bd2d962f221809f25ddb826c9e551b916eb25
Set the mutex owner thread ID.
Original patch from: Prarit Bhargava <prarit@redhat.com>
Link: https://bugzilla.kernel.org/show_bug.cgi?id=115121
Link: https://github.com/acpica/acpica/commit/7a3bd2d9
Signed-off-by: Prarit Bhargava <prarit@redhat.com>
Tested-by: Andy Lutomirski <luto@kernel.org> # On a Dell XPS 13 9350
Signed-off-by: Bob Moore <robert.moore@intel.com>
Signed-off-by: Lv Zheng <lv.zheng@intel.com>
Cc: All applicable <stable@vger.kernel.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
When transportation of the command completes successfully, it indicates
that the 'status' result is valid. Fix the missed checking and
translation of the status field at the end of acpi_nfit_ctl().
Otherwise, we fail to handle reported errors and assume commands
complete successfully.
Reported-by: Linda Knippers <linda.knippers@hpe.com>
Reviewed-by: Johannes Thumshirn <jthumshirn@suse.de>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
|
|
Similar to pci-sysfs export the subsystem information available in the
NFIT. ACPI 6.1 clarifies that this data is copied as an array of bytes
from the DIMM SPD data.
Reported-by: Ryon Jensen <ryon.jensen@intel.com>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
|
|
ACPI6.1 clarifies that DCR fields are stored as an array of bytes,
update the format interface code constants to match.
Reviewed-by: Toshi Kani <toshi.kani@hpe.com>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
|
|
There are currently 4 known similar but incompatible definitions of the
command sets that can be sent to an NVDIMM through ACPI. It is also
clear that future platform generations (ACPI or not) will continue to
revise and extend the DIMM command set as new devices and use cases
arrive.
It is obviously untenable to continue to proliferate divergence
of these command definitions, and to that end a standardization process
has begun to provide for a unified specification. However, that leaves a
problem about what to do with this first generation where vendors are
already shipping divergence.
The Linux kernel can support these initial diverged platforms without
giving platform-firmware free reign to continue to diverge and compound
kernel maintenance overhead. The kernel implementation can encourage
standardization in two ways:
1/ Require that any function code that userspace wants to send be
explicitly white-listed in the implementation. For ACPI this means
function codes marked as supported by acpi_check_dsm() may
only be invoked if they appear in the white-list. A function must be
publicly documented before it is added to the white-list.
2/ The above restrictions can be trivially bypassed by using the
"vendor-specific" payload command. However, since vendor-specific
commands are by definition not publicly documented and have the
potential to corrupt the kernel's view of the dimm state, we provide a
toggle to disable vendor-specific operations. Enabling undefined
behavior is a policy decision that can be made by the platform owner
and encourages firmware implementations to choose public over
private command implementations.
Based on an initial patch from Jerry Hoemann
Cc: Jerry Hoemann <jerry.hoemann@hpe.com>
Cc: Christoph Hellwig <hch@infradead.org>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
|
|
Clarify the distinction between "commands", the ioctls userspace calls
to request the kernel take some action on a given dimm device, and
"_DSMs", the actual function numbers used in the firmware interface to
the DIMM. _DSMs are ACPI specific whereas commands are Linux kernel
generic.
This is in preparation for breaking the 1:1 implicit relationship
between the kernel ioctl number space and the firmware specific function
numbers.
Cc: Jerry Hoemann <jerry.hoemann@hpe.com>
Cc: Christoph Hellwig <hch@infradead.org>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
|
|
This flag is a no-op now (see commit 47b0eeb3dc8a "clk: Deprecate
CLK_IS_ROOT", 2016-02-02) so remove it.
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
Acked-by: Graeme Gregory <graeme.gregory@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
This flag is a no-op now (see commit 47b0eeb3dc8a "clk: Deprecate
CLK_IS_ROOT", 2016-02-02) so remove it.
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
ACPI 6.1, section 5.2.25.9, defines an identifier for an NVDIMM.
Change the NFIT driver to add a new sysfs file "id" under nfit
directory.
Signed-off-by: Toshi Kani <toshi.kani@hpe.com>
Cc: Rafael J. Wysocki <rjw@rjwysocki.net>
Cc: Dan Williams <dan.j.williams@intel.com>
Cc: Robert Moore <robert.moore@intel.com>
Cc: Robert Elliott <elliott@hpe.com>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
|
|
ACPI 6.1, Table 5-133, updates NVDIMM Control Region Structure
as follows.
- Valid Fields, Manufacturing Location, and Manufacturing Date
are added from reserved range. No change in the structure size.
- IDs (SPD values) are stored as arrays of bytes (i.e. big-endian
format). The spec clarifies that they need to be represented
as arrays of bytes as well.
This patch makes the following changes to support this update.
- Change the NFIT driver to show SPD ID values in big-endian
format.
- Change sprintf format to use "0x" instead of "#" since "%#02x"
does not prepend '0'.
link: http://www.uefi.org/sites/default/files/resources/ACPI_6_1.pdf
Signed-off-by: Toshi Kani <toshi.kani@hpe.com>
Cc: Rafael J. Wysocki <rjw@rjwysocki.net>
Cc: Dan Williams <dan.j.williams@intel.com>
Cc: Robert Moore <robert.moore@intel.com>
Cc: Robert Elliott <elliott@hpe.com>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
|
|
When ACPI was originally merged for arm64 it had only been tested on
emulators and not on real physical platforms and no platforms were
relying on it. This meant that there were concerns that there might be
serious issues attempting to use it on practical systems so it had a
dependency on EXPERT added to warn people that it was in an early stage
of development with very little practical testing. Since then things
have moved on a bit. We have seen people testing on real hardware and
now have people starting to produce some platforms (the most prominent
being the 96boards Cello) which only have ACPI support and which build
and run to some useful extent with mainline.
This is not to say that ACPI support or support for these systems is
completely done, there are still areas being worked on such as PCI, but
at this point it seems that we can be reasonably sure that ACPI will be
viable for use on ARM64 and that the already merged support works for
the cases it handles. For the AMD Seattle based platforms support
outside of PCI has been fairly complete in mainline a few releases now.
This is also not to say that we don't have vendors working with ACPI who
are trying do things that we would not consider optimal but it does not
appear that the EXPERT dependency is having a substantial impact on
these vendors.
Given all this it seems that at this point the EXPERT dependency mainly
creates inconvenience for users with systems that are doing the right
thing and gets in the way of including the ACPI code in the testing that
people are doing on mainline. Removing it should help our ongoing
testing cover those platforms with only ACPI support and help ensure
that when ACPI code is merged any problems it causes for other users are
more easily discovered.
Signed-off-by: Mark Brown <broonie@kernel.org>
Acked-by: Graeme Gregory <graeme.gregory@linaro.org>
Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Al Stone <ahs3@redhat.com>
Acked-by: Hanjun Guo <hanjun.guo@linaro.org>
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
Acked-by: Roy Franz <roy.franz@hpe.com>
Acked-by: Olof Johansson <olof@lixom.net>
Acked-by: Timur Tabi <timur@codeaurora.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
If ACPI is selectable it is enabled by default. This is a good choice
for architectures where the overwhelming majority of systems use ACPI
like x86 and IA-64 but is less clear for architectures where it's less
common like ARM64. Change the default selection so that it's only done
explicitly on those architectures where ACPI is universally used.
Signed-off-by: Mark Brown <broonie@kernel.org>
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
Acked-by: Hanjun Guo <hanjun.guo@linaro.org>
Acked-by: Olof Johansson <olof@lixom.net>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
SRAT maps APIC ID to proximity domains ids (PXM). Mapping from PXM to
NUMA node ids is based on order of entries in SRAT table.
SRAT table has just LAPIC entires or mix of LAPIC and X2APIC entries.
As long as there are only LAPIC entires, mapping from proximity domain
id to NUMA node id is as assumed by BIOS. However, once APIC entries are
mixed, X2APIC entries would be first mapped which causes unexpected NUMA
node mapping.
To fix that, change parsing to check each entry against both LAPIC and
X2APIC so mapping is in the SRAT/PXM order.
This is supplemental change to the fix made by commit d81056b5278
(Handle apic/x2apic entries in MADT in correct order) and using the
mechanism introduced by 9b3fedd (ACPI / tables: Add acpi_subtable_proc
to ACPI table parsers).
Fixes: d81056b5278 (Handle apic/x2apic entries in MADT in correct order)
Signed-off-by: Lukasz Anaczkowski <lukasz.anaczkowski@intel.com>
[ rjw : Subject & changelog ]
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
This patch converts the initrd table override mechanism to the table
upgrade mechanism by restricting its usage to the tables released with
compatibility and more recent revision.
This use case has been encouraged by the ACPI specification:
1. OEMID:
An OEM-supplied string that identifies the OEM.
2. OEM Table ID:
An OEM-supplied string that the OEM uses to identify the particular data
table. This field is particularly useful when defining a definition
block to distinguish definition block functions. OEM assigns each
dissimilar table a new OEM Table Id.
3. OEM Revision:
An OEM-supplied revision number. Larger numbers are assumed to be newer
revisions.
For OEMs, good practices will ensure consistency when assigning OEMID and
OEM Table ID fields in any table. The intent of these fields is to allow
for a binary control system that support services can use. Because many
support function can be automated, it is useful when a tool can
programatically determine which table release is a compatible and more
recent revision of a prior table on the same OEMID and OEM Table ID.
The facility can now be used by the vendors to upgrade wrong tables for bug
fixing purpose, thus lockdep disabling taint is not suitable for it and it
should be a default 'y' option to implement the spec encouraged use case.
Note that, by implementing table upgrade inside of ACPICA itself, it is
possible to remove acpi_table_initrd_override() and tables can be upgraded
by acpi_install_table() automatically. Though current ACPICA impelentation
hasn't implemented this, this patched changes the table flag setting timing
to allow this to be implemented in ACPICA without changing the code here.
Documentation of initrd override mechanism is upgraded accordingly.
Original-by: Octavian Purdila <octavian.purdila@intel.com>
Signed-off-by: Lv Zheng <lv.zheng@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
This patch moves acpi_os_table_override() and
acpi_os_physical_table_override() to tables.c.
Along with the mechanisms, acpi_initrd_initialize_tables() is also moved to
tables.c to form a static function. The following functions are renamed
according to this change:
1. acpi_initrd_override() -> renamed to early_acpi_table_init(), which
invokes acpi_table_initrd_init()
2. acpi_os_physical_table_override() -> which invokes
acpi_table_initrd_override()
3. acpi_initialize_initrd_tables() -> renamed to acpi_table_initrd_scan()
Signed-off-by: Lv Zheng <lv.zheng@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
The ACPI specification states that arguments "Revision ID" and "Function
Index" to a _DSM are type "Integer." Type Integers are 64 bit
quantities.
The function evaluate_dsm specifies these types as simple "int" which
are 32 bits. Widen type passed to acpi_evaluate_dsm and its callers and
derived callers to pass correct type.
acpi_check_dsm and acpi_evaluate_dsm_typed had similar issue and were
corrected as well.
This is in preparation for libnvdimm implementing a generic _DSM
passthrough facility to have the capacity to pass 64-bit values as the
ACPI specification allows.
[djbw: clarify the changelog, add rationale]
Signed-off-by: Jerry Hoemann <jerry.hoemann@hpe.com>
Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
|
|
It's minor but that's still better to use ACPI_SIG_NFIT instead of hard
coded string.
Cc: Ross Zwisler <ross.zwisler@linux.intel.com>
Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>
Cc: Len Brown <lenb@kernel.org>
Signed-off-by: Lee, Chun-Yi <jlee@suse.com>
Acked-by: Ross Zwisler <ross.zwisler@linux.intel.com>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
|
|
Starting with ACPI 6.1 an NFIT table will report multiple 'NVDIMM
Control Region Structure' instances per-dimm, one for each supported
format interface. Report that code in the following format in sysfs:
nmemX/nfit/formats
nmemX/nfit/format
nmemX/nfit/format1
nmemX/nfit/format2
...
nmemX/nfit/formatN
Where format2 - formatN are theoretical as there are no known DIMMs with
support for more than two interface formats.
This layout is compatible with existing libndctl binaries that only
expect one code per-dimm as they will ignore nmemX/nfit/formats and
nmemX/nfit/formatN.
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
|
|
acpi_dev_present() was originally named after pci_dev_present()
to signify the similarity of the two functions.
However Rafael J. Wysocki pointed out that the exported function
acpi_dev_present() is easily confused with the non-exported
acpi_device_is_present(). Additionally in ACPI parlance the term
"present" usually refers to the "device is present" bit returned
by the _STA control method, yet acpi_dev_present() merely checks
presence in the namespace. It does not invoke _STA at all, let
alone check the "device is present" bit.
As suggested by Rafael, rename the function to acpi_dev_found()
and adjust all existing call sites.
Signed-off-by: Lukas Wunner <lukas@wunner.de>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
With wrong ECDT fixes reverted, it is possible to put ECDT probing before
acpi_enable_subsystem().
But the ultimate purpose of ECDT re-enabling is to put the ECDT probing
before the namespace initialization (acpi_load_tables()). This patch
achieves this with protections so that we can enable it later when all
necessary corrections are upstreamed.
Link 4: https://bugzilla.kernel.org/show_bug.cgi?id=112911
Signed-off-by: Lv Zheng <lv.zheng@intel.com>
Tested-by: Chris Bainbridge <chris.bainbridge@gmail.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
All operation region accesses are allowed by AML interpreter when AML is
executed, so actually BIOSen are responsible to avoid the operation region
accesses in AML before OSPM has prepared an operation region driver. This
is done via _REG control method. So AML code normally sets a global named
object REGC to 1 when _REG(3, 1) is evaluated.
Then what is ECDT? Quoting from ACPI spec 6.0, 5.2.15 Embedded Controller
Boot Resources Table (ECDT):
"The presence of this table allows OSPM to provide Embedded Controller
operation region space access before the namespace has been evaluated."
Spec also suggests a compatible mean to indicate the early EC access
availability:
Device (EC)
{
Name (REGC, Ones)
Method (_REG, 2)
{
If (LEqual (Arg0, 3))
{
Store (Arg1, REGC)
}
}
Method (ECAV)
{
If (LEqual (REGC, Ones))
{
If (LGreaterEqual (_REV, 2))
{
Return (One)
}
Else
{
Return (Zero)
}
}
Else
{
Return (REGC)
}
}
}
In this way, it allows EC accesses to happen before EC._REG(3, 1) is
invoked.
But ECAV is not the only way practical BIOSen using to indicate the early
EC access availibility, the known variations include:
1. Setting REGC to One in \_SB._INI when _REV >= 2. Since \_SB._INI is the
first control method evaluated by OSPM during the enumeration, this
allows EC accesses to happen for the entire enumeration process before
the namespace EC is enumerated.
2. Initialize REGC to One by default, this even allows EC accesses to
happen during the table loading.
Linux is now broken around ECDT support during the long term bug fixing
work because it has merged many wrong ECDT bug fixes (see details below).
Linux currently uses namespace EC's settings instead of ECDT settings when
ECDT is detected. This apparently will result in namespace walk and
_CRS/_GPE/_REG evaluations. Such stuffs could only happen after namespace
is ready, while ECDT is purposely to be used before namespace is ready.
The wrong bug fixing story is:
1. Link 1:
At Linux ACPI early stages, "no _Lxx/_Exx/_Qxx evaluation can happen
before the namespace is ready" are not ensured by ACPICA core and Linux.
This is currently ensured by deferred enabling of GPE and defered
registering of EC query methods (acpi_ec_register_query_methods).
2. Link 2:
Reporters reported buggy ECDTs, expecting quirks for the platform.
Originally, the quirk is simple, only doing things with ECDT.
Bug 9399 and 12461 are platforms (Asus L4R, Asus M6R, MSI MS-171F)
reported to have wrong ECDT IO port addresses, the port addresses are
reversed.
Bug 11880 is a platform (Asus X50GL) reported to have 0 valued port
addresses, we can see that all EC accesses are protected by ECAV on
this platform, so actually no early EC accesses is required by this
platform.
3. Link 3:
But when the bug fixing developer was requested to provide a handy and
non-quirk bug fix, he tried to use correct EC settings from namespace
and broke the spec purpose. We can even see that the developer was
suffered from many regrssions. One interesting one is 14086, where the
actual root cause obviously should be: _REG is evaluated too early. But
unfortunately, the bug is fixed in a totally wrong way.
So everything goes wrong from these commits:
Commit: c6cb0e878446c79f42e7833d7bb69ed6bfbb381f
Subject: ACPI: EC: Don't trust ECDT tables from ASUS
Commit: a5032bfdd9c80e0231a6324661e123818eb46ecd
Subject: ACPI: EC: Always parse EC device
This patch reverts Linux behavior to simple ECDT quirk support in order to
stop early _CRS/_GPE/_REG evaluations.
For Bug 9399, 12461, since it is reported that the platforms require early
EC accesses, this patch restores the simple ECDT quirks for them.
For Bug 11880, since it is not reported that the platform requires early EC
accesses and its ACPI tables contain correct ECAV, we choose an ECDT
enumeration failure for this platform.
Link 1: https://bugzilla.kernel.org/show_bug.cgi?id=9916
http://bugzilla.kernel.org/show_bug.cgi?id=10100
https://lkml.org/lkml/2008/2/25/282
Link 2: https://bugzilla.kernel.org/show_bug.cgi?id=9399
https://bugzilla.kernel.org/show_bug.cgi?id=12461
https://bugzilla.kernel.org/show_bug.cgi?id=11880
Link 3: https://bugzilla.kernel.org/show_bug.cgi?id=11884
https://bugzilla.kernel.org/show_bug.cgi?id=14081
https://bugzilla.kernel.org/show_bug.cgi?id=14086
https://bugzilla.kernel.org/show_bug.cgi?id=14446
Link 4: https://bugzilla.kernel.org/show_bug.cgi?id=112911
Signed-off-by: Lv Zheng <lv.zheng@intel.com>
Tested-by: Chris Bainbridge <chris.bainbridge@gmail.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
This patch splits EC_FLAGS_HANDLERS_INSTALLED so that address space handler
can be installed when it is not possible to install GPE handler during
early stage.
This patch also tunes address space handler installation, making it
happening earlier than GPE handler installation for the same purpose.
Since acpi_ec_start()/acpi_ec_stop() will be entered multiple times after
applying this change, it is also required to protect acpi_enable_gpe()/
acpi_disable_gpe() invocations.
Link: https://bugzilla.kernel.org/show_bug.cgi?id=112911
Signed-off-by: Lv Zheng <lv.zheng@intel.com>
Tested-by: Chris Bainbridge <chris.bainbridge@gmail.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
The problem is Linux registers pm_power_off = efi_power_off only if
we are in hardware reduced mode. Actually, what we also want is to do
this when ACPI S5 is simply not supported on non-legacy platforms.
Since some future Intel platforms are HW-full mode where the DSDT
fails to supply an _S5 object(without SLP_TYP), we should let such
kind of platform to leverage efi runtime service to poweroff.
This patch uses efi power off as first choice when S5 is unavailable,
even if there is a customized poweroff(driver provided, eg).
Meanwhile, the legacy platforms will not be affected because there is
no path for them to overwrite the pm_power_off to efi power off.
Suggested-by: Len Brown <len.brown@intel.com>
Reviewed-by: Matt Fleming <matt@codeblueprint.co.uk>
Signed-off-by: Chen Yu <yu.c.chen@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
Generic Event Device described in ACPI 6.1 allows platforms to handle
platform interrupts in ACPI ASL statements. It borrows constructs like
_EVT from GPIO events. All interrupts are listed in _CRS and the handler
is written in _EVT method. Here is an example.
Device (GED0)
{
Name (_HID, "ACPI0013")
Name (_UID, 0)
Name(_CRS, ResourceTemplate ()
{
Interrupt(ResourceConsumer, Edge, ActiveHigh, Shared, , , )
{123}
})
Method (_EVT, 1) {
if (Lequal(123, Arg0))
{
}
}
}
Wake capability has not been implemented yet.
Signed-off-by: Sinan Kaya <okaya@codeaurora.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
_REG evaluations
ACPICA commit f005ee6b90d152c1f499efcca6b771a93903cb55
This patch splits \_SB._INI evaluation from device initialization code, so
that it can be performed before PCI_Config _REG evaluations. This is
required for the device enumeration process. Some named objects are
initialized in \_SB._INI and PCI_Config _REG evaluations may use
uninitialized named objects because of the order issue.
This must be fixed before fixing ECDT order issue. There are existing
tables allowing ECDT EC to be used for the entire device enumeration
process, but the enabling of ECDT EC is done in \_SB._INI. Thus \_SB._INI
must be the first control method evaluated in the device enumeration
process. Normally, the order should be automatically ensured by the device
enumeration process itself (for example, PCI_Config _REGs are evaluated by
the PCI bus driver when the driver is probed by the enumeration process),
but since the process is split on Linux (partially done in Linux, partially
done in ACPICA), we need to ensure this with special logics in order to be
regression safe. Lv Zheng.
Link: https://github.com/acpica/acpica/commit/f005ee6b
Signed-off-by: Lv Zheng <lv.zheng@intel.com>
Signed-off-by: Bob Moore <robert.moore@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
namespace is initialized
ACPICA commit c508f8592efaa0d8197f26d7fee6382c5ac8e383
Current code flow cannot ensure _REG association can happen after the
namespace is initialized, so we move _REG association to where _REG was
about to run to fix this issue.
This issue is detected when acpi_ev_initialize_region() is invoked during
the table loading. And this is one of the most important the root cause why
ACPICA table loading is split into 2 load passes. Lv Zheng.
Link: https://github.com/acpica/acpica/commit/c508f859
Link: https://bugs.acpica.org/show_bug.cgi?id=1252
Signed-off-by: Lv Zheng <lv.zheng@intel.com>
Signed-off-by: Bob Moore <robert.moore@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
ACPICA commit 5798cd6171ea38bcf4594d0ccc78870784776ba5
The patch corrects wrong condition before group MLC is disabled.
Link: https://github.com/acpica/acpica/commit/5798cd61
Link: https://bugs.acpica.org/show_bug.cgi?id=1262
Signed-off-by: Lv Zheng <lv.zheng@intel.com>
Signed-off-by: Bob Moore <robert.moore@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
acpi_ev_install_region_handlers() invocation
ACPICA commit 9a6ecc9ec9ee067cad51eec539230bf494421d76
Since AE_ALREADY_EXISTS has already been converted to AE_OK in
acpi_ev_install_region_handlers(), this patch simplies a return value
check. Lv Zheng.
Link: https://github.com/acpica/acpica/commit/9a6ecc9e
Signed-off-by: Lv Zheng <lv.zheng@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
access_width/bit_offset awareness
ACPICA commit 997a90f810a4cb78604ef2e187611a181b498286
This patch enhances acpi_hw_validate_register() to sanitize register
accesses with awareness of access_width and bit_offset. Lv Zheng.
Link: https://github.com/acpica/acpica/commit/997a90f8
Link: https://bugs.acpica.org/show_bug.cgi?id=1240
Signed-off-by: Lv Zheng <lv.zheng@intel.com>
Signed-off-by: Bob Moore <robert.moore@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
Some compilers require parentheses to be enforced in the macro definition,
so that the macro caller side can be simpler.
This patch fixes this kind of macro issue in
ACPI_SET_BITS()/ACPI_GET_BITS(). Lv Zheng.
Link: https://bugs.acpica.org/show_bug.cgi?id=1268
Signed-off-by: Lv Zheng <lv.zheng@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
ACPICA commit cbcb77565c5032dd48e19b3a8a8b8704c5f29faf
This patch adds a macro ACPI_IS_POWER_OF_TWO, which can be used to
detect if a number is a power of two. Lv Zheng.
Link: https://github.com/acpica/acpica/commit/cbcb7756
Signed-off-by: Lv Zheng <lv.zheng@intel.com>
Signed-off-by: Bob Moore <robert.moore@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
ACPICA commit 16cd0872a070c8d3b16b8b13c1fc90a443a6b6fe
If the definition of a control method cannot be found (probably it
is in another module/SSDT), the disassembler must try to guess
at the number of arguments to that method. This change improves
the guessing heuristic.
Link: https://github.com/acpica/acpica/commit/16cd0872
Signed-off-by: Bob Moore <robert.moore@intel.com>
Signed-off-by: Lv Zheng <lv.zheng@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
ACPICA commit a240cbb93647bddf525b3daf6e9d31b8b9bca34e
Integrated most changes proposed by net_BSD.
>From joerg@net_BSD.org (Joerg Sonnenberger)
ACPICA BZ 732.
Link: https://github.com/acpica/acpica/commit/a240cbb9
Link: https://bugs.acpica.org/show_bug.cgi?id=732
Signed-off-by: Bob Moore <robert.moore@intel.com>
Signed-off-by: Lv Zheng <lv.zheng@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
ACPICA commit 795e136d2ac77c1c8b091fba019b5fe36a44a323
Fixes a problem with the merger of the two internal versions
of this function. Make the maximum integer width (32-bit or
64-bit) a parameter to the function so that it no longer
exclusively uses the integer width specified in the DSDT/SSDT.
ACPICA BZ 1260
Link: https://github.com/acpica/acpica/commit/795e136d
Signed-off-by: Bob Moore <robert.moore@intel.com>
Signed-off-by: Lv Zheng <lv.zheng@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
ACPICA commit 9ed98dc36645aaeba11967722951156650d94f47
For consistency, cleanup function invocations.
Link: https://github.com/acpica/acpica/commit/9ed98dc3
Signed-off-by: Bob Moore <robert.moore@intel.com>
Signed-off-by: Lv Zheng <lv.zheng@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
ACPICA commit 0e6125401cf38427d5376f4bafbfb3d5a40f8467
Use local variables for access to string/value Op fields.
Move duplicate PLD string tables to a single common table.
Link: https://github.com/acpica/acpica/commit/0e612540
Signed-off-by: Bob Moore <robert.moore@intel.com>
Signed-off-by: Lv Zheng <lv.zheng@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
ACPICA commit e068948f49eb61a78c211028976a174604c5644a
Fix some issues in the exutils.c file.
Link: https://github.com/acpica/acpica/commit/e068948f
Signed-off-by: Bob Moore <robert.moore@intel.com>
Signed-off-by: Lv Zheng <lv.zheng@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
ACPICA commit 60d9cfd403a9824199b971597c930f6f563e5c71
Allows all object types to be used with Concatenate. Objects
other than Int/Str/Buf are convert to a string that contains
the type of the object. Improves the utility of the Printf
and Fprintf macros.
Adds a new file, exconcat.c
Link: https://github.com/acpica/acpica/commit/60d9cfd4
Signed-off-by: Bob Moore <robert.moore@intel.com>
Signed-off-by: Lv Zheng <lv.zheng@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
ACPICA commit 5f21bddaa2cec035ca80608803ce2f0858d4f387
Small changes:
1) A couple new predefined names
2) New _HID values
3) New subtable for HEST
Link: https://github.com/acpica/acpica/commit/5f21bdda
Signed-off-by: Bob Moore <robert.moore@intel.com>
Signed-off-by: Lv Zheng <lv.zheng@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
ACPICA commit bca0c4cb063ee488c543e6f160fe89679a2338d6
Update a warning message
simplify versioning for "table too big" case.
Link: https://github.com/acpica/acpica/commit/bca0c4cb
Signed-off-by: Bob Moore <robert.moore@intel.com>
Signed-off-by: Lv Zheng <lv.zheng@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
The patch reduces source code differences between the Linux kernel and the
ACPICA upstream so that the linuxized ACPICA 20160212 release can be
applied with reduced human intervention.
Signed-off-by: Lv Zheng <lv.zheng@intel.com>
[ rjw: White space damage fixes ]
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
* acpi-processor:
ACPI / processor: Request native thermal interrupt handling via _OSC
|
|
There are several reports of freeze on enabling HWP (Hardware PStates)
feature on Skylake-based systems by the Intel P-states driver. The root
cause is identified as the HWP interrupts causing BIOS code to freeze.
HWP interrupts use the thermal LVT which can be handled by Linux
natively, but on the affected Skylake-based systems SMM will respond
to it by default. This is a problem for several reasons:
- On the affected systems the SMM thermal LVT handler is broken (it
will crash when invoked) and a BIOS update is necessary to fix it.
- With thermal interrupt handled in SMM we lose all of the reporting
features of the arch/x86/kernel/cpu/mcheck/therm_throt driver.
- Some thermal drivers like x86-package-temp depend on the thermal
threshold interrupts signaled via the thermal LVT.
- The HWP interrupts are useful for debugging and tuning
performance (if the kernel can handle them).
The native handling of thermal interrupts needs to be enabled
because of that.
This requires some way to tell SMM that the OS can handle thermal
interrupts. That can be done by using _OSC/_PDC in processor
scope very early during ACPI initialization.
The meaning of _OSC/_PDC bit 12 in processor scope is whether or
not the OS supports native handling of interrupts for Collaborative
Processor Performance Control (CPPC) notifications. Since on
HWP-capable systems CPPC is a firmware interface to HWP, setting
this bit effectively tells the firmware that the OS will handle
thermal interrupts natively going forward.
For details on _OSC/_PDC refer to:
http://www.intel.com/content/www/us/en/standards/processor-vendor-specific-acpi-specification.html
To implement the _OSC/_PDC handshake as described, introduce a new
function, acpi_early_processor_osc(), that walks the ACPI
namespace looking for ACPI processor objects and invokes _OSC for
them with bit 12 in the capabilities buffer set and terminates the
namespace walk on the first success.
Also modify intel_thermal_interrupt() to clear HWP status bits in
the HWP_STATUS MSR to acknowledge HWP interrupts (which prevents
them from firing continuously).
Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
[ rjw: Subject & changelog, function rename ]
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm
Pull more power management and ACPI updates from Rafael Wysocki:
"The second batch of power management and ACPI updates for v4.6.
Included are fixups on top of the previous PM/ACPI pull request and
other material that didn't make into it but still should go into 4.6.
Among other things, there's a fix for an intel_pstate driver issue
uncovered by recent cpufreq changes, a workaround for a boot hang on
Skylake-H related to the handling of deep C-states by the platform and
a PCI/ACPI fix for the handling of IO port resources on non-x86
architectures plus some new device IDs and similar.
Specifics:
- Fix for an intel_pstate driver issue related to the handling of MSR
updates uncovered by the recent cpufreq rework (Rafael Wysocki).
- cpufreq core cleanups related to starting governors and frequency
synchronization during resume from system suspend and a locking fix
for cpufreq_quick_get() (Rafael Wysocki, Richard Cochran).
- acpi-cpufreq and powernv cpufreq driver updates (Jisheng Zhang,
Michael Neuling, Richard Cochran, Shilpasri Bhat).
- intel_idle driver update preventing some Skylake-H systems from
hanging during initialization by disabling deep C-states mishandled
by the platform in the problematic configurations (Len Brown).
- Intel Xeon Phi Processor x200 support for intel_idle
(Dasaratharaman Chandramouli).
- cpuidle menu governor updates to make it always honor PM QoS
latency constraints (and prevent C1 from being used as the fallback
C-state on x86 when they are set below its exit latency) and to
restore the previous behavior to fall back to C1 if the next timer
event is set far enough in the future that was changed in 4.4 which
led to an energy consumption regression (Rik van Riel, Rafael
Wysocki).
- New device ID for a future AMD UART controller in the ACPI driver
for AMD SoCs (Wang Hongcheng).
- Rockchip rk3399 support for the rockchip-io-domain adaptive voltage
scaling (AVS) driver (David Wu).
- ACPI PCI resources management fix for the handling of IO space
resources on architectures where the IO space is memory mapped
(IA64 and ARM64) broken by the introduction of common ACPI
resources parsing for PCI host bridges in 4.4 (Lorenzo Pieralisi).
- Fix for the ACPI backend of the generic device properties API to
make it parse non-device (data node only) children of an ACPI
device correctly (Irina Tirdea).
- Fixes for the handling of global suspend flags (introduced in 4.4)
during hibernation and resume from it (Lukas Wunner).
- Support for obtaining configuration information from Device Trees
in the PM clocks framework (Jon Hunter).
- ACPI _DSM helper code and devfreq framework cleanups (Colin Ian
King, Geert Uytterhoeven)"
* tag 'pm+acpi-4.6-rc1-2' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm: (23 commits)
PM / AVS: rockchip-io: add io selectors and supplies for rk3399
intel_idle: Support for Intel Xeon Phi Processor x200 Product Family
intel_idle: prevent SKL-H boot failure when C8+C9+C10 enabled
ACPI / PM: Runtime resume devices when waking from hibernate
PM / sleep: Clear pm_suspend_global_flags upon hibernate
cpufreq: governor: Always schedule work on the CPU running update
cpufreq: Always update current frequency before startig governor
cpufreq: Introduce cpufreq_update_current_freq()
cpufreq: Introduce cpufreq_start_governor()
cpufreq: powernv: Add sysfs attributes to show throttle stats
cpufreq: acpi-cpufreq: make Intel/AMD MSR access, io port access static
PCI: ACPI: IA64: fix IO port generic range check
ACPI / util: cast data to u64 before shifting to fix sign extension
cpufreq: powernv: Define per_cpu chip pointer to optimize hot-path
cpuidle: menu: Fall back to polling if next timer event is near
cpufreq: acpi-cpufreq: Clean up hot plug notifier callback
intel_pstate: Do not call wrmsrl_on_cpu() with disabled interrupts
cpufreq: Make cpufreq_quick_get() safe to call
ACPI / property: fix data node parsing in acpi_get_next_subnode()
ACPI / APD: Add device HID for future AMD UART controller
...
|
|
* acpi-soc:
ACPI / APD: Add device HID for future AMD UART controller
* acpi-misc:
ACPI / util: cast data to u64 before shifting to fix sign extension
* acpi-pci:
PCI: ACPI: IA64: fix IO port generic range check
* device-properties:
ACPI / property: fix data node parsing in acpi_get_next_subnode()
|
|
* pm-avs:
PM / AVS: rockchip-io: add io selectors and supplies for rk3399
* pm-clk:
PM / clk: Add support for obtaining clocks from device-tree
* pm-devfreq:
PM / devfreq: Spelling s/frequnecy/frequency/
* pm-sleep:
ACPI / PM: Runtime resume devices when waking from hibernate
PM / sleep: Clear pm_suspend_global_flags upon hibernate
|
|
Commit 58a1fbbb2ee8 ("PM / PCI / ACPI: Kick devices that might have been
reset by firmware") added a runtime resume for devices that were runtime
suspended when the system entered suspend-to-RAM.
Briefly, the motivation was to ensure that devices did not remain in a
reset-power-on state after resume, potentially preventing deep SoC-wide
low-power states from being entered on idle.
Currently we're not doing the same when leaving suspend-to-disk and this
asymmetry is a problem if drivers rely on the automatic resume triggered
by pm_complete_with_resume_check(). Fix it.
Fixes: 58a1fbbb2ee8 (PM / PCI / ACPI: Kick devices that might have been reset by firmware)
Signed-off-by: Lukas Wunner <lukas@wunner.de>
Cc: 4.4+ <stable@vger.kernel.org> # 4.4+
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
