We've been suffering from the uncertainty of the SCI_EVT clearing timing.
This patch implements 3 of 4 possible modes to handle SCI_EVT clearing
variations. The old behavior is kept in this patch.
Status: QR_EC is re-checked as early as possible after checking previous
SCI_EVT. This always leads to 2 QR_EC transactions per SCI_EVT
indication and the target may implement event queue which returns
0x00 indicating "no outstanding event".
This is proven to be a conflict against Windows behavior, but is
still kept in this patch to make the EC driver robust to the
possible regressions that may occur on Samsung platforms.
Query: QR_EC is re-checked after the target has handled the QR_EC query
request command pushed by the host.
Event: QR_EC is re-checked after the target has noticed the query event
response data pulled by the host.
This timing is not determined by any IRQs, so we may need to use a
guard period in this mode, which may explain the existence of the
ec_guard() code used by the old EC driver where the re-check timing
is implemented in the similar way as this mode.
Method: QR_EC is re-checked as late as possible after completing the _Qxx
evaluation. The target may implement SCI_EVT like a level triggered
interrupt.
It is proven on kernel bugzilla 94411 that, Windows will have all
_Qxx evaluations parallelized. Thus unless required by further
evidences, we needn't implement this mode as it is a conflict of
the _Qxx parallelism requirement.
Note that, according to the reports, there are platforms that cannot be
handled using the "Status" mode without enabling the
EC_FLAGS_QUERY_HANDSHAKE quirk. But they can be handled with the other
modes according to the tests (kernel bugzilla 97381).
The following log entry can be used to confirm the differences of the 3
modes as it should appear at the different positions for the 3 modes:
Command(QR_EC) unblocked
Status: appearing after
EC_SC(W) = 0x84
Query: appearing after
EC_DATA(R) = 0xXX
where XX is the event number used to determine _QXX
Event: appearing after first
EC_SC(R) = 0xX0 SCI_EVT=x BURST=0 CMD=0 IBF=0 OBF=0
that is next to the following log entry:
Command(QR_EC) completed by hardware
Link: https://bugzilla.kernel.org/show_bug.cgi?id=94411
Link: https://bugzilla.kernel.org/show_bug.cgi?id=97381
Link: https://bugzilla.kernel.org/show_bug.cgi?id=98111
Reported-and-tested-by: Gabriele Mazzotta <gabriele.mzt@gmail.com>
Reported-and-tested-by: Tigran Gabrielyan <tigrangab@gmail.com>
Reported-and-tested-by: Adrien D <ghbdtn@openmailbox.org>
Signed-off-by: Lv Zheng <lv.zheng@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
During the period that a work queue is scheduled (queued up for run) but
hasn't been run, second schedule_work() could fail. This may not lead to
the loss of queries because QR_EC is always ensured to be submitted after
the work queue has been in the running state.
The event handling work queue can be changed into the loop style to allow
us to control the code in a more flexible way:
1. Makes it possible to add event=0x00 termination condition in the loop.
2. Increases the thoughput of the QR_EC transactions as the 2nd+ QR_EC
transactions may be handled in the same work item used for the 1st QR_EC
transaction, thus the delay caused by the 2nd+ work item scheduling can
be eliminated.
Except the logging message changes and the throughput improvement, this
patch is just a funcitonal no-op.
Signed-off-by: Lv Zheng <lv.zheng@intel.com>
Tested-by: Gabriele Mazzotta <gabriele.mzt@gmail.com>
Tested-by: Tigran Gabrielyan <tigrangab@gmail.com>
Tested-by: Adrien D <ghbdtn@openmailbox.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
This patch collects transaction state transition code into one function. We
then could have a single function to maintain transaction transition
related behaviors. No functional changes.
Signed-off-by: Lv Zheng <lv.zheng@intel.com>
Tested-by: Gabriele Mazzotta <gabriele.mzt@gmail.com>
Tested-by: Tigran Gabrielyan <tigrangab@gmail.com>
Tested-by: Adrien D <ghbdtn@openmailbox.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Make the button ACPI device ID array static const. Safes us a little bit
of code.
Signed-off-by: Mathias Krause <minipli@googlemail.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
There is no need to have processor_power_dmi_table[] writeable, constify
it.
Signed-off-by: Mathias Krause <minipli@googlemail.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Constify the acpi_hed_ids[] ACPI device IDs array -- no need to have it
writeable.
Signed-off-by: Mathias Krause <minipli@googlemail.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
The device descriptors are never written to -- even pointed to as
'const' from struct lpss_private_data. Make them r/o for real.
Signed-off-by: Mathias Krause <minipli@googlemail.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
The bat_dmi_table[] DMI table is referenced from the __init function
acpi_battery_init_async() only. It and its referenced functions can
therefore be marked __initconst to free up ~1kB of runtime memory after
initialization is done.
Signed-off-by: Mathias Krause <minipli@googlemail.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Make the acpi_battery_units() function take a const argument and return
a const char*, too. Also make it static. It probably doesn't matter, as
gcc will be clever enough to optimize and inline the code even without
these hints. However, we also get rid of a #ifdef block by moving the
function closer to its usage location, so it's at least a small gain in
code readability.
Signed-off-by: Mathias Krause <minipli@googlemail.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
The offset tables are only read, not modified. Make them const.
Signed-off-by: Mathias Krause <minipli@googlemail.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
There is no need to have ac_dmi_table[] writeable, constify it.
Signed-off-by: Mathias Krause <minipli@googlemail.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Make the video ACPI device ID array static and constify the DMI system
IDs array. Saves us a little bit of code.
Signed-off-by: Mathias Krause <minipli@googlemail.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
On some systems acpi-video backlight is broken in the sense that it cannot
control the brightness of the backlight, but it must still be called on
resume to power-up the backlight after resume.
This commit allows these systems to work by going through all the usual
backlight control moves, while not registering a sysfs backlight
interface.
This commit also adds a quirk enabling this parameter on Toshiba Portege
R830 systems which are known to be affected by this.
I wish there was a better way to deal with this, but we've been unable to
find one.
Link: https://bugzilla.kernel.org/show_bug.cgi?id=21012
Link: https://bugs.freedesktop.org/show_bug.cgi?id=82634
Reported-and-tested-by: Sylvain Pasche <sylvain.pasche@gmail.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Aaron Lu <aaron.lu@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
It seems that the latest generation of MacbookPro needs to use the
native backlight driver, just like most modern laptops do, but it does
not automatically get enabled as the Apple BIOS does not advertise
Windows 8 compatibility. So add a quirk for this.
Reported-by: Christopher Beland <beland@alum.mit.edu>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Commit 73f7d1ca32 "ACPI / init: Run acpi_early_init() before
timekeeping_init()" moved the ACPI subsystem initialization,
including the ACPI mode enabling, to an earlier point in the
initialization sequence, to allow the timekeeping subsystem
use ACPI early. Unfortunately, that resulted in boot regressions
on some systems and the early ACPI initialization was moved toward
its original position in the kernel initialization code by commit
c4e1acbb35 "ACPI / init: Invoke early ACPI initialization later".
However, that turns out to be insufficient, as boot is still broken
on the Tyan S8812 mainboard.
To fix that issue, split the ACPI early initialization code into
two pieces so the majority of it still located in acpi_early_init()
and the part switching over the platform into the ACPI mode goes into
a new function, acpi_subsystem_init(), executed at the original early
ACPI initialization spot.
That fixes the Tyan S8812 boot problem, but still allows ACPI
tables to be loaded earlier which is useful to the EFI code in
efi_enter_virtual_mode().
Link: https://bugzilla.kernel.org/show_bug.cgi?id=97141
Fixes: 73f7d1ca32 "ACPI / init: Run acpi_early_init() before timekeeping_init()"
Reported-and-tested-by: Marius Tolzmann <tolzmann@molgen.mpg.de>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Toshi Kani <toshi.kani@hp.com>
Reviewed-by: Hanjun Guo <hanjun.guo@linaro.org>
Reviewed-by: Lee, Chun-Yi <jlee@suse.com>
Add missing invocation of pm_generic_complete() to
acpi_subsys_complete() to allow ->complete callbacks provided
by the drivers of devices using the ACPI PM domain to be executed
during system resume.
Fixes: f25c0ae2b4 (ACPI / PM: Avoid resuming devices in ACPI PM domain during system suspend)
Cc: 3.16+ <stable@vger.kernel.org> # 3.16+
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Nothing in <asm/io.h> uses anything from <linux/vmalloc.h>, so
remove it from there and fix up the resulting build problems
triggered on x86 {64|32}-bit {def|allmod|allno}configs.
The breakages were triggering in places where x86 builds relied
on vmalloc() facilities but did not include <linux/vmalloc.h>
explicitly and relied on the implicit inclusion via <asm/io.h>.
Also add:
- <linux/init.h> to <linux/io.h>
- <asm/pgtable_types> to <asm/io.h>
... which were two other implicit header file dependencies.
Suggested-by: David Miller <davem@davemloft.net>
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
[ Tidied up the changelog. ]
Acked-by: David Miller <davem@davemloft.net>
Acked-by: Takashi Iwai <tiwai@suse.de>
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
Acked-by: Vinod Koul <vinod.koul@intel.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Anton Vorontsov <anton@enomsg.org>
Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Cc: Colin Cross <ccross@android.com>
Cc: David Vrabel <david.vrabel@citrix.com>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Haiyang Zhang <haiyangz@microsoft.com>
Cc: James E.J. Bottomley <JBottomley@odin.com>
Cc: Jaroslav Kysela <perex@perex.cz>
Cc: K. Y. Srinivasan <kys@microsoft.com>
Cc: Kees Cook <keescook@chromium.org>
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Cc: Kristen Carlson Accardi <kristen@linux.intel.com>
Cc: Len Brown <lenb@kernel.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Rafael J. Wysocki <rjw@rjwysocki.net>
Cc: Suma Ramars <sramars@cisco.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Tony Luck <tony.luck@intel.com>
Signed-off-by: Ingo Molnar <mingo@kernel.org>
The PCIe specification, rev 3.0, section 2.2.8.1, contains the following
implementation note:
Virtual Wire Mapping for INTx Interrupts From ARI Devices
The implied Device Number for an ARI Device is 0. When ARI-aware
software (including BIOS and operating system) enables ARI Forwarding in
the Downstream Port immediately above an ARI Device in order to access
its Extended Functions, software must comprehend that the Downstream Port
will use Device Number 0 for the virtual wire mappings of INTx interrupts
coming from all Functions of the ARI Device. If non-ARI-aware software
attempts to determine the virtual wire mappings for Extended Functions,
it can come up with incorrect mappings by examining the traditional
Device Number field and finding it to be non-0.
We account for this in pci_swizzle_interrupt_pin(), but it looks like we
miss it here, looking for a _PRT entry with a slot matching the ARI device
slot number. This can cause errors like:
pcieport 0000:80:03.0: can't derive routing for PCI INT B
sfc 0000:82:01.1: PCI INT B: no GSI
pci_dev.irq is then invalid, resulting in errors for drivers that attempt
to enable INTx on the device. Fix by using slot 0 for ARI enabled devices.
Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Don Dutile <ddutile@redhat.com>
Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
According to Section 7.2 of ACPI 6.0, power resources should
always be enabled and disabled in order given by the "resourceorder"
field of the corresponding Power Resource objects: "Power Resource
levels are enabled from low values to high values and are disabled
from high values to low values."
However, this is not what happens during system resume, because
in that case the enabling/disabling is carried out in the power
resource registration order which may not reflect the ordering
required by the platform.
For this reason, make the ordering of the global list of all
power resources in the system (used by the system resume code)
reflect the one given by the "resourceorder" attributes of the
Power Resource objects in the ACPI namespace and modify
acpi_resume_power_resources() to walk the list in the reverse
order when turning off the power resources that had been off
before the system was suspended.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Use a #defined symbol ACPI_DT_NAMESPACE_HID instead of the PRP0001
string.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Reviewed-by: Hanjun Guo <hanjun.guo@linaro.org>
list_head "list" in struct acpi_prt_entry was used to connect
_PRT entries for PCI irq, but after commit 181380b702 ("PCI/ACPI:
Don't cache _PRT, and don't associate them with bus numbers"),
the list head for _PRT entries was removed, but left "list" in
struct acpi_prt_entry which is useless and stale, remove it now.
Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
Acked-by: Bjorn Helgaas <bhelgaas@google.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
ACPICA commit d6d003556c6fc22e067d5d511577128a661266c3
-t option displays all ACPI tables.
Link: https://github.com/acpica/acpica/commit/d6d00355
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 403b8b0023fd7549b2f9bf818fcc1ba481047b69
If non-AML files are used with the -e option, the disassembler
can fault. The fix is to ensure that all -e files are either
SSDTs or a DSDT. ACPICA BZ 1158.
Link: https://github.com/acpica/acpica/commit/403b8b00
Reference: https://bugs.acpica.org/show_bug.cgi?id=1158
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 e4f0b73c107680841d7dd01cc04ec108df6580bd
There is code in acpi_hw_build_pci_list() destructing returned object
(return_list_head) before touching it while the allocated new object
(list_head) is not tracked correctly to be destructed on the error case,
which is detected as unsecure code by the "Coverity" tool.
This patch fixes this issue by always intializing the returned object in
acpi_hw_build_pci_list() so that the caller of acpi_hw_build_pci_list() needn't
initialize it and always using the returned object to track the new
allocated objects. Lv Zheng.
Link: https://github.com/acpica/acpica/commit/e4f0b73c
Link: https://jira01.devtools.intel.com/browse/LCK-2143
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 29d03840cbab435e8ea82e9339ff9d84535c647d
This patch fixes a resource leak issue in acpi_ds_auto_serialize_method().
It is reported by the "Coverity" tool as unsecure code. Lv Zheng.
Link: https://github.com/acpica/acpica/commit/29d03840
Link: https://jira01.devtools.intel.com/browse/LCK-2142
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 08170904011f1e8f817d9e3a9f2bb2438aeacf60
For the compiler part (not disassembler).
- Characters not within a comment must be be ASCII (0-0x7F), and
now either printable or a "space" character.
Provides better detection of files that cannot be compiled.
This patch only affects iASL which is not in the Linux upstream.
Link: https://github.com/acpica/acpica/commit/08170904
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 7325b59c8b5d1522ded51ae6a76b804f6e8da5d2
Moved from a C module.
Link: https://github.com/acpica/acpica/commit/7325b59c
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 ACPI 6 specification has made some changes in the device power
management area. In particular:
* The D3hot power state is now supposed to be always available
(instead of D3cold) and D3cold is only regarded as valid if the
_PR3 object is present for the given device.
* The required ordering of transitions into power states deeper than
D0 is now such that for a transition into state Dx the _PSx method
is supposed to be executed first, if present, and the states of
the power resources the device depends on are supposed to be
changed after that.
* It is now explicitly forbidden to transition devices from
lower-power (deeper) into higher-power (shallower) power states
other than D0.
Those changes have been made so the specification reflects the
Windows' device power management code that the vast majority of
systems using ACPI is validated against.
To avoid artificial differences in ACPI device power management
between Windows and Linux, modify the ACPI device power management
code to follow the new specification. Add comments explaining the
code flow in some unclear places.
This only may affect some real corner cases in which the OS behavior
expected by the firmware is different from the Windows one, but that's
quite unlikely. The transition ordering change affects transitions
to D1 and D2 which are rarely used (if at all) and into D3hot and
D3cold for devices actually having _PR3, but those are likely to
be validated against Windows anyway. The other changes may affect
code calling acpi_device_get_power() or acpi_device_update_power()
where ACPI_STATE_D3_HOT may be returned instead of ACPI_STATE_D3_COLD
(that's why the ACPI fan driver needs to be updated too) and since
transitions into ACPI_STATE_D3_HOT may remove power now, it is better
to avoid this one in acpi_pm_device_sleep_state() if the "no power
off" PM QoS flag is set.
The only existing user of acpi_device_can_poweroff() really cares
about the case when _PR3 is present, so the change in that function
should not cause any problems to happen too.
A plus is that PCI_D3hot can be mapped to ACPI_STATE_D3_HOT
now and the compatibility with older systems should be covered
automatically.
In any case, if any real problems result from this, it still will
be better to follow the Windows' behavior (which now is reflected
by the specification too) in general and handle the cases when it
doesn't work via quirks.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
{ Update to correct 1 patch subject in the description }
We have fixed a lot of race issues in the EC driver recently.
The following commit introduces MSI udelay()/msleep() quirk to MSI laptops
to make EC firmware working for bug 12011 without root causing any EC
driver race issues:
Commit: 5423a0cb3f
Subject: ACPI: EC: Add delay for slow MSI controller
Commit: 34ff4dbccc
Subject: ACPI: EC: Separate delays for MSI hardware
The following commit extends ECDT validation quirk to MSI laptops to make
EC driver locating EC registers properly for bug 12461:
Commit: a5032bfdd9
Subject: ACPI: EC: Always parse EC device
This is a different quirk than the MSI udelay()/msleep() quirk. This patch
keeps validating ECDT for only "Micro-Star MS-171F" as reported.
The following commit extends MSI udelay()/msleep() quirk to Quanta laptops
to make EC firmware working for bug 20242, there is no requirement to
validate ECDT for Quanta laptops:
Commit: 534bc4e3d2 Mon Sep 17 00:00:00 2001
Subject: ACPI EC: enable MSI workaround for Quanta laptops
The following commit extends MSI udelay()/msleep() quirk to Clevo laptops
to make EC firmware working for bug 77431, there is no requirement to
validate ECDT for Clevo laptops:
Commit: 777cb38295
Subject: ACPI / EC: Add msi quirk for Clevo W350etq
All udelay()/msleep() quirks for MSI/Quanta/Clevo seem to be the wrong
fixes generated without fixing the EC driver race issues.
And even if it is not wrong, the guarding can be covered by the following
commits in wait polling mode:
Commit: 9e295ac14d
Subject: ACPI / EC: Reduce ec_poll() by referencing the last register access timestamp.
Commit: commit in the same series
Subject: ACPI / EC: Fix and clean up register access guarding logics.
The only case that is not covered is the inter-transaction guarding. And
there is no evidence that we need the inter-transaction guarding upon
reading the noted bug entries.
So it is time to remove the quirks and let the users to try again. If there
is a regression, the only thing we need to do is to restore the
inter-transaction guarding for the reported platforms.
Link: https://bugzilla.kernel.org/show_bug.cgi?id=12011
Link: https://bugzilla.kernel.org/show_bug.cgi?id=12461
Link: https://bugzilla.kernel.org/show_bug.cgi?id=20242
Link: https://bugzilla.kernel.org/show_bug.cgi?id=77431
Signed-off-by: Lv Zheng <lv.zheng@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
We have 2 polling modes in the EC driver:
1. busy polling: originally used for the MSI quirks. udelay() is used to
perform register access guarding.
2. wait polling: normal code path uses wait_event_timeout() and it can be
woken up as soon as the transaction is completed in the interrupt mode.
It also contains the register acces guarding logic in case the interrupt
doesn't arrive and the EC driver is about to advance the transaction in
task context (the polling mode).
The wait polling is useful for interrupt mode to allow other tasks to use
the CPU during the wait.
But for the polling mode, the busy polling takes less time than the wait
polling, because if no interrupt arrives, the wait polling has to wait the
minimal HZ interval.
We have a new use case for using the busy polling mode. Some GPIO drivers
initialize PIN configuration which cause a GPIO multiplexed EC GPE to be
disabled out of the GPE register's control. Busy polling mode is useful
here as it takes less time than the wait polling. But the guarding logic
prevents it from responding even faster. We should spinning around the EC
status rather than spinning around the nop execution lasted a determined
period.
This patch introduces 2 module params for the polling mode switch and the
guard time, so that users can use the busy polling mode without the
guarding in case the guarding is not necessary. This is an example to use
the 2 module params for this purpose:
acpi.ec_busy_polling acpi.ec_polling_guard=0
We've tested the patch on a test platform. The platform suffers from such
kind of the GPIO PIN issue. The GPIO driver resets all PIN configuration
and after that, EC interrupt cannot arrive because of the multiplexing.
Then the platform suffers from a long delay carried out by the
wait_event_timeout() as all further EC transactions will run in the polling
mode. We switched the EC driver to use the busy polling mechanism instead
of the wait timeout polling mechanism and the delay is still high:
[ 44.283005] calling PNP0C0B:00+ @ 1305, parent: platform
[ 44.417548] call PNP0C0B:00+ returned 0 after 131323 usecs
And this patch can significantly reduce the delay:
[ 44.502625] calling PNP0C0B:00+ @ 1308, parent: platform
[ 44.503760] call PNP0C0B:00+ returned 0 after 1103 usecs
Tested-by: Chen Yu <yu.c.chen@intel.com>
Signed-off-by: Lv Zheng <lv.zheng@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
In the polling mode, EC driver shouldn't access the EC registers too
frequently. Though this statement is concluded from the non-root caused
bugs (see links below), we've maintained the register access guarding
logics in the current EC driver. The guarding logics can be found here and
there, makes it hard to root cause real timing issues. This patch collects
the guarding logics into one single function so that all hidden logics
related to this can be seen clearly.
The current guarding related code also has several issues:
1. Per-transaction timestamp prevents inter-transaction guarding from being
implemented in the same place. We have an inter-transaction udelay() in
acpi_ec_transaction_unblocked(), this logic can be merged into ec_poll()
if we can use per-device timestamp. This patch completes such merge to
form a new ec_guard() function and collects all guarding related hidden
logics in it.
One hidden logic is: there is no inter-transaction guarding performed
for non MSI quirk (wait polling mode), this patch skips
inter-transaction guarding before wait_event_timeout() for the wait
polling mode to reveal the hidden logic.
The other hidden logic is: there is msleep() inter-transaction guarding
performed when the GPE storming is observed. As after merging this
commit:
Commit: e1d4d90fc0
Subject: ACPI / EC: Refine command storm prevention support
EC_FLAGS_COMMAND_STORM is ensured to be cleared after invoking
acpi_ec_transaction_unlocked(), the msleep() guard logic will never
happen now. Since no one complains such change, this logic is likely
added during the old times where the EC race issues are not fixed and
the bugs are false root-caused to the timing issue. This patch simply
removes the out-dated logic. We can restore it by stop skipping
inter-transaction guarding for wait polling mode.
Two different delay values are defined for msleep() and udelay() while
they are merged in this patch to 550us.
2. time_after() causes additional delay in the polling mode (can only be
observed in noirq suspend/resume processes where polling mode is always
used) before advance_transaction() is invoked ("wait polling" log is
added before wait_event_timeout()). We can see 2 wait_event_timeout()
invocations. This is because time_after() ensures a ">" validation while
we only need a ">=" validation here:
[ 86.739909] ACPI: Waking up from system sleep state S3
[ 86.742857] ACPI : EC: 2: Increase command
[ 86.742859] ACPI : EC: ***** Command(RD_EC) started *****
[ 86.742861] ACPI : EC: ===== TASK (0) =====
[ 86.742871] ACPI : EC: EC_SC(R) = 0x20 SCI_EVT=1 BURST=0 CMD=0 IBF=0 OBF=0
[ 86.742873] ACPI : EC: EC_SC(W) = 0x80
[ 86.742876] ACPI : EC: ***** Event started *****
[ 86.742880] ACPI : EC: ~~~~~ wait polling ~~~~~
[ 86.743972] ACPI : EC: ~~~~~ wait polling ~~~~~
[ 86.747966] ACPI : EC: ===== TASK (0) =====
[ 86.747977] ACPI : EC: EC_SC(R) = 0x20 SCI_EVT=1 BURST=0 CMD=0 IBF=0 OBF=0
[ 86.747978] ACPI : EC: EC_DATA(W) = 0x06
[ 86.747981] ACPI : EC: ~~~~~ wait polling ~~~~~
[ 86.751971] ACPI : EC: ~~~~~ wait polling ~~~~~
[ 86.755969] ACPI : EC: ===== TASK (0) =====
[ 86.755991] ACPI : EC: EC_SC(R) = 0x21 SCI_EVT=1 BURST=0 CMD=0 IBF=0 OBF=1
[ 86.755993] ACPI : EC: EC_DATA(R) = 0x03
[ 86.755994] ACPI : EC: ~~~~~ wait polling ~~~~~
[ 86.755995] ACPI : EC: ***** Command(RD_EC) stopped *****
[ 86.755996] ACPI : EC: 1: Decrease command
This patch corrects this by using time_before() instead in ec_guard():
[ 54.283146] ACPI: Waking up from system sleep state S3
[ 54.285414] ACPI : EC: 2: Increase command
[ 54.285415] ACPI : EC: ***** Command(RD_EC) started *****
[ 54.285416] ACPI : EC: ~~~~~ wait polling ~~~~~
[ 54.285417] ACPI : EC: ===== TASK (0) =====
[ 54.285424] ACPI : EC: EC_SC(R) = 0x20 SCI_EVT=1 BURST=0 CMD=0 IBF=0 OBF=0
[ 54.285425] ACPI : EC: EC_SC(W) = 0x80
[ 54.285427] ACPI : EC: ***** Event started *****
[ 54.285429] ACPI : EC: ~~~~~ wait polling ~~~~~
[ 54.287209] ACPI : EC: ===== TASK (0) =====
[ 54.287218] ACPI : EC: EC_SC(R) = 0x20 SCI_EVT=1 BURST=0 CMD=0 IBF=0 OBF=0
[ 54.287219] ACPI : EC: EC_DATA(W) = 0x06
[ 54.287222] ACPI : EC: ~~~~~ wait polling ~~~~~
[ 54.291190] ACPI : EC: ===== TASK (0) =====
[ 54.291210] ACPI : EC: EC_SC(R) = 0x21 SCI_EVT=1 BURST=0 CMD=0 IBF=0 OBF=1
[ 54.291213] ACPI : EC: EC_DATA(R) = 0x03
[ 54.291214] ACPI : EC: ~~~~~ wait polling ~~~~~
[ 54.291215] ACPI : EC: ***** Command(RD_EC) stopped *****
[ 54.291216] ACPI : EC: 1: Decrease command
After cleaning up all guarding logics, we have one single function
ec_guard() collecting all old, non-root-caused, hidden logics. Then we can
easily tune the logics in one place to respond to the bug reports.
Except the time_before() change, all other changes do not change the
behavior of the EC driver.
Link: https://bugzilla.kernel.org/show_bug.cgi?id=12011
Link: https://bugzilla.kernel.org/show_bug.cgi?id=20242
Link: https://bugzilla.kernel.org/show_bug.cgi?id=77431
Signed-off-by: Lv Zheng <lv.zheng@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
The following commit merges polling and interrupt modes for EC driver:
Commit: 2a84cb9852 Mon Sep 17 00:00:00 2001
Subject: ACPI: EC: Merge IRQ and POLL modes
The irqs_disabled() check introduced in it tries to fall into busy polling
mode when the context of ec_poll() cannot sleep.
Actually ec_poll() is ensured to be invoked in the contexts that can sleep
(from a sysfs /sys/kernel/debug/ec/ec0/io access, or from
acpi_evaluate_object(), or from acpi_ec_gpe_poller()). Without the MSI
quirk, we never saw the udelay() logic invoked. Thus this check is useless
and can be removed.
Signed-off-by: Lv Zheng <lv.zheng@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
This patch removes the storming threashold enlarging quirk.
After applying the following commit, we can notice that there is no no-op
GPE handling invocation can be observed, thus it is unlikely that the
no-op counts can exceed the storming threashold:
Commit: ca37bfdfbc
Subject: ACPI / EC: Fix several GPE handling issues by deploying ACPI_GPE_DISPATCH_RAW_HANDLER mode.
Even when the storming happens, we have already limited its affection to
the only transaction and no further transactions will be affected. This is
done by this commit:
Commit: e1d4d90fc0
Subject: ACPI / EC: Refine command storm prevention support
So it's time to remove this quirk.
Link: https://bugzilla.kernel.org/show_bug.cgi?id=45151
Signed-off-by: Lv Zheng <lv.zheng@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
This patch updates acpi_ec_is_gpe_raised() according to the following
commit:
Commit: 09af8e8290
Subject: ACPICA: Events: Add support to return both enable/status register values for GPE and fixed event.
This is actually a no-op change as both the flags are defined to a same
value.
Signed-off-by: Lv Zheng <lv.zheng@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
In the definition of struct acpi_predefined_names, value is of
type char *. Make the OSL override function also work with type
char * (or, more precisely, with a pointer to it).
Signed-off-by: Dominik Brodowski <linux@dominikbrodowski.net>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Make sure that async function scheduled with async_schedule() has already
been executed.
Signed-off-by: Luis Henriques <luis.henriques@canonical.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
If ACPI is disabled there's no need to schedule an async function call,
the driver initialization can be aborted earlier in acpi_battery_init().
Signed-off-by: Luis Henriques <luis.henriques@canonical.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Introduce invalid_phys_cpuid() to identify cpu with invalid
physical ID, then used it as replacement of the direct comparisons
with PHYS_CPUID_INVALID.
Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Since invalid_logical_cpuid() can check error values, so
return specific error instead of -1 for acpi_map_cpuid().
Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Use pr->phys_id to replace phys_id to simplify the code.
Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Just use pr->id instead of cpu_index to simplify the code.
Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
In ACPI processor drivers, we use direct comparisons of cpu logical
id with -1 which are error prone in case logical cpuid is accidentally
assinged an error code and prevents us from returning an error-encoding
cpuid directly in some cases.
So introduce invalid_logical_cpuid() to identify cpu with invalid
logical cpu num, then it will be used to replace the direct comparisons
with -1.
Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Revert commit b1ef297258 (ACPICA: Permanently set _REV to the value
'2'.) as it causes a sound regression to happen on Dell XPS 13 (2015).
Reported-by: Dominik Brodowski <linux@dominikbrodowski.net>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
An old comment in acpi_power_transition() indicates that support
for ordering power resources needs to be added, but the current
code handles that already.
Drop the comment to avoid confusion.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* acpi-resources:
x86/PCI/ACPI: Make all resources except [io 0xcf8-0xcff] available on PCI bus
* acpi-battery:
ACPI / SBS: Add 5 us delay to fix SBS hangs on MacBook
* acpi-doc:
ACPI / documentation: Fix ambiguity in the GPIO properties document
ACPI / documentation: fix a sentence about GPIO resources
* acpi-pnp:
ACPI / PNP: add two IDs to list for PNPACPI device enumeration
Since acpi_reserve_resources() is defined as a device_initcall(),
there's no guarantee that it will be executed in the right order
with respect to the rest of the ACPI initialization code. On some
systems this leads to breakage if, for example, the address range
that should be reserved for the ACPI fixed registers is given to
the PCI host bridge instead if the race is won by the wrong code
path.
Fix this by turning acpi_reserve_resources() into a void function
and calling it directly from within the ACPI initialization sequence.
Reported-and-tested-by: George McCollister <george.mccollister@gmail.com>
Link: http://marc.info/?t=143092384600002&r=1&w=2
Cc: All applicable <stable@vger.kernel.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
The ACPI procfs power interface is initialized by compilation units
that are only selectable on X86 platforms. Since its usage is
deprecated and it cannot even be used on platforms other than X86
it should be compiled in only on X86 platforms.
This patch makes CONFIG_ACPI_PROCFS_POWER dependent on X86, so
that other architectures are prevented from compiling it in for
no purpose.
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Acked-by: Hanjun Guo <hanjun.guo@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Refine the check for the presence of the "compatible" property
if the PRP0001 device ID is present in the device's list of
ACPI/PNP IDs to also print the message if _DSD is missing
entirely or the format of it is incorrect.
One special case to take into accout is that the "compatible"
property need not be provided for devices having the PRP0001
device ID in their lists of ACPI/PNP IDs if they are ancestors
of PRP0001 devices with the "compatible" property present.
This is to cover heriarchies of device objects where the kernel
is only supposed to use a struct device representation for the
topmost one and the others represent, for example, functional
blocks of a composite device.
While at it, reduce the log level of the message to "info"
and reduce the log level of the "broken _DSD" message to
"debug" (noise reduction).
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Currently you can specify the weight of the cooling device in the device
tree but that information is not populated to the
thermal_bind_params where the fair share governor expects it to
be. The of thermal zone device doesn't have a thermal_bind_params
structure and arguably it's better to pass the weight inside the
thermal_instance as it is specific to the bind of a cooling device to a
thermal zone parameter.
Core thermal code is fixed to populate the weight in the instance from
the thermal_bind_params, so platform code that was passing the weight
inside the thermal_bind_params continue to work seamlessly.
While we are at it, create a default value for the weight parameter for
those thermal zones that currently don't define it and remove the
hardcoded default in of-thermal.
Cc: Zhang Rui <rui.zhang@intel.com>
Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>
Cc: Len Brown <lenb@kernel.org>
Cc: Peter Feuerer <peter@piie.net>
Cc: Darren Hart <dvhart@infradead.org>
Cc: Eduardo Valentin <edubezval@gmail.com>
Cc: Kukjin Kim <kgene@kernel.org>
Cc: Durgadoss R <durgadoss.r@intel.com>
Signed-off-by: Kapileshwar Singh <kapileshwar.singh@arm.com>
Signed-off-by: Eduardo Valentin <edubezval@gmail.com>
This is the result of us seeing this during boot
[ 24.332560] INFO: NMI handler (ghes_notify_nmi) took too long to run: 3.265 msecs
[ 24.332567] INFO: NMI handler (ghes_notify_nmi) took too long to run: 5.946 msecs
[ 24.332568] INFO: NMI handler (ghes_notify_nmi) took too long to run: 5.948 msecs
and a report of people running perf stat and the machine softlocking.
"hest_disable" was helping in this case, which made us look at that
particular NMI handler. It was grabbing a lock each time it is run and
on each CPU. But this is not needed as the GHES sources are global and
they need only a single reader.
This patchset does that and cleans up the handler in the process.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQIcBAABAgAGBQJVRzqjAAoJEBLB8Bhh3lVKFQUQAKmPPaWp2qPUkRHtrdFfae0n
Um9PSAHlvO8oHPrr+5j+CEVX1gQ1qUFMuxSVuBYYhmMZnsAVCwKX8gOi3slZmElo
L0MoqxygP2v3Rc79Jk8KEkov+80zzp46VoB5Yh0mTfzSejeS+c1owwS0RzVIpda3
Zp1cAThTVsCdDmmWGhnWfc8T/wniPc2zbbVhtjivO/wwSu7ArWUR5/03pbxzex8M
3xnJY29USB62xO5OJf0mxAIhTqv4a7NSQ6NziBrI2Mt4inHj0oSR7KLVFpeSx4mX
LLo8dWfDpMIbwd2sZYg5fG6Kz2i3Cc5I252V4j7MI+srvvZzZPBr1aB8qNyQVGPF
grrQKQuD2Az0WZRo2gK2LvxvlHfmJyOJMaFPW+RMnARbtKMmmAIwaN4+zmPGHoH8
aQK7cKUyb1JxICpy9iAZjXMvqxc5zbhYra0G+zuLKruhEvmLrwibphjI82BNdaBZ
rhkK+cw47lPgwKVNRWKjpNGGziwqU2cBlmc50k9OyQhhv5HF2TeYyBRryykOVmLV
DpsUxO4rCj0YEioyoJEruBO1Ks167HGrg5sbSemO/YeM7wLgr7hMfVNlGM4DI68X
b3Ie81/7qD8d3nQZ/gkk8ex1D0QhS0FWZthbNKpvkX+Zc/ELbGhfgHxX55HmfGuD
DUmvP2oXlALAIPiJAYVP
=Qj+0
-----END PGP SIGNATURE-----
Merge tag 'ras_for_4.2' of git://git.kernel.org/pub/scm/linux/kernel/git/ras/ras into acpi-apei
Pull GHES changes for 4.2 from Borislav Petkov:
"GHES: Seriously speedup and cleanup NMI handler (Jiri Kosina and Borislav Petkov)
This is the result of us seeing this during boot
[ 24.332560] INFO: NMI handler (ghes_notify_nmi) took too long to run: 3.265 msecs
[ 24.332567] INFO: NMI handler (ghes_notify_nmi) took too long to run: 5.946 msecs
[ 24.332568] INFO: NMI handler (ghes_notify_nmi) took too long to run: 5.948 msecs
and a report of people running perf stat and the machine softlocking.
"hest_disable" was helping in this case, which made us look at that
particular NMI handler. It was grabbing a lock each time it is run and
on each CPU. But this is not needed as the GHES sources are global and
they need only a single reader.
This patchset does that and cleans up the handler in the process."
* tag 'ras_for_4.2' of git://git.kernel.org/pub/scm/linux/kernel/git/ras/ras:
GHES: Make NMI handler have a single reader
GHES: Elliminate double-loop in the NMI handler
GHES: Panic right after detection
GHES: Carve out the panic functionality
GHES: Carve out error queueing in a separate function
Commit eec15edbb0 (ACPI / PNP: use device ID list for PNPACPI device
enumeration) changed the way how ACPI devices are enumerated and when
they are added to the PNP bus.
However, it broke the sound card support on (at least) a vintage
IBM ThinkPad 600E: with said commit applied, two of the necessary
"CSC01xx" devices are not added to the PNP bus and hence can not be
found during the initialization of the "snd-cs4236" module. As a
consequence, loading "snd-cs4236" causes null pointer exceptions.
The attached patch fixes the problem end re-enables sound on the
IBM ThinkPad 600E.
Fixes: eec15edbb0 (ACPI / PNP: use device ID list for PNPACPI device enumeration)
Signed-off-by: Witold Szczeponik <Witold.Szczeponik@gmx.net>
Cc: 3.16+ <stable@vger.kernel.org> # 3.16+
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Commit 7bc5a2bad0 'ACPI: Support _OSI("Darwin") correctly' caused
the MacBook firmware to expose the SBS, resulting in intermittent
hangs of several minutes on boot, and failure to detect or report
the battery. Fix this by adding a 5 us delay to the start of each
SMBUS transaction. This timing is the result of experimentation -
hangs were observed with 3 us but never with 5 us.
Fixes: 7bc5a2bad0 'ACPI: Support _OSI("Darwin") correctly'
Link: https://bugzilla.kernel.org/show_bug.cgi?id=94651
Signed-off-by: Chris Bainbridge <chris.bainbridge@gmail.com>
Cc: 3.18+ <stable@vger.kernel.org> # 3.18+
[ rjw: Subject and changelog ]
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
An IO port or MMIO resource assigned to a PCI host bridge may be
consumed by the host bridge itself or available to its child
bus/devices. The ACPI specification defines a bit (Producer/Consumer)
to tell whether the resource is consumed by the host bridge itself,
but firmware hasn't used that bit consistently, so we can't rely on it.
Before commit 593669c2ac ("x86/PCI/ACPI: Use common ACPI resource
interfaces to simplify implementation"), arch/x86/pci/acpi.c ignored
all IO port resources defined by acpi_resource_io and
acpi_resource_fixed_io to filter out IO ports consumed by the host
bridge itself.
Commit 593669c2ac ("x86/PCI/ACPI: Use common ACPI resource interfaces
to simplify implementation") started accepting all IO port and MMIO
resources, which caused a regression that IO port resources consumed
by the host bridge itself became available to its child devices.
Then commit 63f1789ec7 ("x86/PCI/ACPI: Ignore resources consumed by
host bridge itself") ignored resources consumed by the host bridge
itself by checking the IORESOURCE_WINDOW flag, which accidently removed
MMIO resources defined by acpi_resource_memory24, acpi_resource_memory32
and acpi_resource_fixed_memory32.
On x86 and IA64 platforms, all IO port and MMIO resources are assumed
to be available to child bus/devices except one special case:
IO port [0xCF8-0xCFF] is consumed by the host bridge itself
to access PCI configuration space.
So explicitly filter out PCI CFG IO ports[0xCF8-0xCFF]. This solution
will also ease the way to consolidate ACPI PCI host bridge common code
from x86, ia64 and ARM64.
Related ACPI table are archived at:
https://bugzilla.kernel.org/show_bug.cgi?id=94221
Related discussions at:
http://patchwork.ozlabs.org/patch/461633/https://lkml.org/lkml/2015/3/29/304
Fixes: 63f1789ec7 (Ignore resources consumed by host bridge itself)
Reported-by: Bernhard Thaler <bernhard.thaler@wvnet.at>
Signed-off-by: Jiang Liu <jiang.liu@linux.intel.com>
Cc: 4.0+ <stable@vger.kernel.org> # 4.0+
Reviewed-by: Bjorn Helgaas <bhelgaas@google.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Commit 9faf6136ff (ACPI / SBS: Disable smart battery manager on
Apple) introduced a regression disabling the SBS battery manager.
The battery manager should be marked as present when
acpi_manager_get_info() returns 0.
Fixes: 9faf6136ff (ACPI / SBS: Disable smart battery manager on Apple)
Signed-off-by: Chris Bainbridge <chris.bainbridge@gmail.com>
Cc: 3.18+ <stable@vger.kernel.org> # 3.18+
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Since GHES sources are global, we theoretically need only a single CPU
reading them per NMI instead of a thundering herd of CPUs waiting on a
spinlock in NMI context for no reason at all.
Do that.
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Signed-off-by: Borislav Petkov <bp@suse.de>
There's no real need to iterate twice over the HW error sources in the
NMI handler. With the previous cleanups, elliminating the second loop is
almost trivial.
Signed-off-by: Borislav Petkov <bp@suse.de>
The moment we log an error of panic severity, there's no need to noodle
through the ghes_nmi list anymore. So panic instead right then and
there.
Signed-off-by: Borislav Petkov <bp@suse.de>
- Fix a build warning in the intel_pstate driver showing up in non-SMP
builds (Borislav Petkov).
- Change one of the intel_pstate's P-state selection parameters for
Baytrail and Cherrytrail CPUs to significantly improve performance
at the cost of a small increase in energy consumption (Kristen
Carlson Accardi).
- Fix a NULL pointer dereference in the ACPI EC driver due to an unsafe
list walk in the query handler removal routine (Chris Bainbridge).
- Get rid of a false-positive lockdep warning in the ACPI container
hot-remove code (Rafael J Wysocki).
- Prevent the ACPI device enumeration code from creating device
objects of a wrong type in some cases (Rafael J Wysocki).
- Add Skylake processors support to the Intel RAPL power capping
driver (Brian Bian).
- Drop the stale MAINTAINERS entry for the ACPI dock driver that is
regarded as part of the ACPI core and maintained along with it now
(Chao Yu).
- Fix cpupower tool breakage caused by a library API change in libpci
3.3.0 (Lucas Stach).
/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
iQIcBAABCAAGBQJVOoMNAAoJEILEb/54YlRxx+QP/A/gaX9GgB6rv627Khlaw2AK
PpE1SrJoU9jAEwPqXtRnYc/6nducDzO5XaHOdWaV02YCpKLL5vIyia6wcy7cf4kr
6vJUnBz0OiHjp4e4sYrvIGt7RrLnlodayKAzNgtjDjF2JE3gzOOldD0klcfisiUP
Uc7Y3bpFndS8fwpcJO0tGm73aA9kNC5N8sYxgtuv/OAeMmJgi0fIi2V227XIurJU
48nMJ1v7M3OChmhdfxEtUSR9TM8J0Ck3yJwPYORNFItRCGqHJb3WY6lo1kbNcv1g
SLwbw+nCaq+E4k2PtDAsg68Ni0uGGnytcBTzhtPeUOdPRulp4CHCnZEyMUBwFVV8
gZlgL2S3CxcBlZ52hVB9tAhAyRcxmaWrp1v/hNsTh1xX9v9JFUFdpjYvk1RlHKwD
aT30G1mV8icU9lrYzhNOnh9gMrZVv6wy4sp4Uk1NLa17WXu+p0LMrCX8HJEb3PT3
rYZ8jbzo422lTksopiLTLhY4ipgX+kysa7NhTtw/J5Hb9xctho0uTsIhP6sSkh2e
eHO8WthEpF36228n6qiGGTBMcs4xPD8goxXCeBmgsBeVAQDaVR1IcArVTS+HAaJX
KOhemws+ThpEpjqB8jbpa42OEmY1Um3UUufHwnJIX54vGkSlXBxXE9r3hCwK7Mgu
hQhnM9hargHcy9Z8vd91
=0bKD
-----END PGP SIGNATURE-----
Merge tag 'pm+acpi-4.1-rc1-2' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm
Pull more power management and ACPI updates from Rafael Wysocki:
"These are fixes mostly (intel_pstate, ACPI core, ACPI EC driver,
cpupower tool), a new CPU ID for the Intel RAPL driver and one
intel_pstate driver improvement that didn't make it to my previous
pull requests due to timing.
Specifics:
- Fix a build warning in the intel_pstate driver showing up in
non-SMP builds (Borislav Petkov)
- Change one of the intel_pstate's P-state selection parameters for
Baytrail and Cherrytrail CPUs to significantly improve performance
at the cost of a small increase in energy consumption (Kristen
Carlson Accardi)
- Fix a NULL pointer dereference in the ACPI EC driver due to an
unsafe list walk in the query handler removal routine (Chris
Bainbridge)
- Get rid of a false-positive lockdep warning in the ACPI container
hot-remove code (Rafael J Wysocki)
- Prevent the ACPI device enumeration code from creating device
objects of a wrong type in some cases (Rafael J Wysocki)
- Add Skylake processors support to the Intel RAPL power capping
driver (Brian Bian)
- Drop the stale MAINTAINERS entry for the ACPI dock driver that is
regarded as part of the ACPI core and maintained along with it now
(Chao Yu)
- Fix cpupower tool breakage caused by a library API change in libpci
3.3.0 (Lucas Stach)"
* tag 'pm+acpi-4.1-rc1-2' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm:
ACPI / scan: Add a scan handler for PRP0001
ACPI / scan: Annotate physical_node_lock in acpi_scan_is_offline()
ACPI / EC: fix NULL pointer dereference in acpi_ec_remove_query_handler()
MAINTAINERS: remove maintainship entry of docking station driver
powercap / RAPL: Add support for Intel Skylake processors
cpufreq: intel_pstate: Fix an annoying !CONFIG_SMP warning
intel_pstate: Change the setpoint for Atom params
cpupower: fix breakage from libpci API change
This series introduces preliminary ACPI 5.1 support to the arm64 kernel
using the "hardware reduced" profile. We don't support any peripherals
yet, so it's fairly limited in scope:
- Memory init (UEFI)
- ACPI discovery (RSDP via UEFI)
- CPU init (FADT)
- GIC init (MADT)
- SMP boot (MADT + PSCI)
- ACPI Kconfig options (dependent on EXPERT)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQEcBAABCgAGBQJVNOC2AAoJELescNyEwWM08dIH/1Pn5xa04wwNDn0MOpbuQMk2
kHM7hx69fbXflTJpnZRVyFBjRxxr5qilA7rljAFLnFeF8Fcll/s5VNy7ElHKLISq
CB0ywgUfOd/sFJH57rcc67pC1b/XuqTbE1u1NFwvp2R3j1kGAEJWNA6SyxIP4bbc
NO5jScx0lQOJ3rrPAXBW8qlGkeUk7TPOQJtMrpftNXlFLFrR63rPaEmMZ9dWepBF
aRE4GXPvyUhpyv5o9RvlN5l8bQttiRJ3f9QjyG7NYhX0PXH3DyvGUzYlk2IoZtID
v3ssCQH3uRsAZHIBhaTyNqFnUIaDR825bvGqyG/tj2Dt3kQZiF+QrfnU5D9TuMw=
=zLJn
-----END PGP SIGNATURE-----
Merge tag 'arm64-upstream' of git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux
Pull initial ACPI support for arm64 from Will Deacon:
"This series introduces preliminary ACPI 5.1 support to the arm64
kernel using the "hardware reduced" profile. We don't support any
peripherals yet, so it's fairly limited in scope:
- MEMORY init (UEFI)
- ACPI discovery (RSDP via UEFI)
- CPU init (FADT)
- GIC init (MADT)
- SMP boot (MADT + PSCI)
- ACPI Kconfig options (dependent on EXPERT)
ACPI for arm64 has been in development for a while now and hardware
has been available that can boot with either FDT or ACPI tables. This
has been made possible by both changes to the ACPI spec to cater for
ARM-based machines (known as "hardware-reduced" in ACPI parlance) but
also a Linaro-driven effort to get this supported on top of the Linux
kernel. This pull request is the result of that work.
These changes allow us to initialise the CPUs, interrupt controller,
and timers via ACPI tables, with memory information and cmdline coming
from EFI. We don't support a hybrid ACPI/FDT scheme. Of course,
there is still plenty of work to do (a serial console would be nice!)
but I expect that to happen on a per-driver basis after this core
series has been merged.
Anyway, the diff stat here is fairly horrible, but splitting this up
and merging it via all the different subsystems would have been
extremely painful. Instead, we've got all the relevant Acks in place
and I've not seen anything other than trivial (Kconfig) conflicts in
-next (for completeness, I've included my resolution below). Nearly
half of the insertions fall under Documentation/.
So, we'll see how this goes. Right now, it all depends on EXPERT and
I fully expect people to use FDT by default for the immediate future"
* tag 'arm64-upstream' of git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux: (31 commits)
ARM64 / ACPI: make acpi_map_gic_cpu_interface() as void function
ARM64 / ACPI: Ignore the return error value of acpi_map_gic_cpu_interface()
ARM64 / ACPI: fix usage of acpi_map_gic_cpu_interface
ARM64: kernel: acpi: honour acpi=force command line parameter
ARM64: kernel: acpi: refactor ACPI tables init and checks
ARM64: kernel: psci: let ACPI probe PSCI version
ARM64: kernel: psci: factor out probe function
ACPI: move arm64 GSI IRQ model to generic GSI IRQ layer
ARM64 / ACPI: Don't unflatten device tree if acpi=force is passed
ARM64 / ACPI: additions of ACPI documentation for arm64
Documentation: ACPI for ARM64
ARM64 / ACPI: Enable ARM64 in Kconfig
XEN / ACPI: Make XEN ACPI depend on X86
ARM64 / ACPI: Select ACPI_REDUCED_HARDWARE_ONLY if ACPI is enabled on ARM64
clocksource / arch_timer: Parse GTDT to initialize arch timer
irqchip: Add GICv2 specific ACPI boot support
ARM64 / ACPI: Introduce ACPI_IRQ_MODEL_GIC and register device's gsi
ACPI / processor: Make it possible to get CPU hardware ID via GICC
ACPI / processor: Introduce phys_cpuid_t for CPU hardware ID
ARM64 / ACPI: Parse MADT for SMP initialization
...
If the special PRP0001 device ID is present in the given device's list
of ACPI/PNP IDs and the device has a valid "compatible" property in
the _DSD, it should be enumerated using the default mechanism,
unless some scan handlers match the IDs preceding PRP0001 in the
device's list of ACPI/PNP IDs. In addition to that, no scan handlers
matching the IDs following PRP0001 in that list should be attached
to the device.
To make that happen, define a scan handler that will match PRP0001
and trigger the default enumeration for the matching devices if the
"compatible" property is present for them.
Since that requires the check for platform_id and device->handler
to be removed from acpi_default_enumeration(), move the fallback
invocation of acpi_default_enumeration() to acpi_bus_attach()
(after it's checked if there's a matching ACPI driver for the
device), which is a better place to call it, and do the platform_id
check in there too (device->handler is guaranteed to be unset at
the point where the function is looking for a matching ACPI driver).
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Darren Hart <dvhart@linux.intel.com>
acpi_scan_is_offline() may be called under the physical_node_lock
lock of the given device object's parent, so prevent lockdep from
complaining about that by annotating that instance with
SINGLE_DEPTH_NESTING.
Fixes: caa73ea158 (ACPI / hotplug / driver core: Handle containers in a special way)
Reported-and-tested-by: Xie XiuQi <xiexiuqi@huawei.com>
Reviewed-by: Toshi Kani <toshi.kani@hp.com>
Cc: 3.14+ <stable@vger.kernel.org> # 3.14+
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Use list_for_each_entry_safe for iterating because handler may be freed
in the loop.
BUG: unable to handle kernel NULL pointer dereference at 000000000000002c
IP: [<ffffffff814d69c8>] acpi_ec_put_query_handler+0x7/0x1a
Call Trace:
acpi_ec_remove_query_handler+0x87/0x97
acpi_smbus_hc_remove+0x2a/0x44 [sbshc]
acpi_device_remove+0x7b/0x9a
__device_release_driver+0x7e/0x110
driver_detach+0xb0/0xc0
bus_remove_driver+0x54/0xe0
driver_unregister+0x2b/0x60
acpi_bus_unregister_driver+0x10/0x12
acpi_smb_hc_driver_exit+0x10/0x12 [sbshc]
SyS_delete_module+0x1b8/0x210
system_call_fastpath+0x12/0x6a
Signed-off-by: Chris Bainbridge <chris.bainbridge@gmail.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
- Fix for a GPE handling regression on Dell Latitude D600 that
caused GPE signaling to stop working on that machine, which
appears to be due to a hardware glitch, but it used to work
and it can be made work again in a relativly straightforward
way (Rafael J Wysocki).
- Fix for a mutex unlock regression related to the handling of ACPI
tables introduced during the 3.16 development cycle (Octavian Purdila).
- _REV modification to always return 2 which has been done by all
versions of Windows since NT and the firmware people started to
use it to distinguish between OSes in their AML and do some silly
and wrong things on that basis (Bob Moore).
- Fixes and cleanups related to the acpi_physicall_address data type
including one stable-candidate fix for an issue occasionally occuring
on 64-bit machines running 32-bit kernels where using offsets provided
by the firmware may lead to address overflows (Lv Zheng).
- External() opcode support infrastructure needed for recompiling
disassembled ACPI tables in some cases including interpreter
modification to ignore that opcode (Bob Moore).
- Support for the "Windows 2015" string in _OSI (Bob Moore).
- GPE debug interface change to return values read from hardware
registers (Lv Zheng).
- Removal of the __DATE__ macro usage in tools (Rasmus Villemoes).
- Assorted minor fixes and cleanups (Lv Zheng, Rickard Strandqvist,
Bob Moore).
/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
iQIcBAABCAAGBQJVMFyLAAoJEILEb/54YlRxCdgQAK5C0mkWOYgvNr5/Mur3bhgJ
kwa/IDRWKFB6EU4vIEK5sVR4IHGknbRo4XskVt5aHTLgSHWY/ArvACs0nruCR9+s
hvlwqtWuZlqlDNQrP9XuP10CjDvbhEijWo05TmfeI52Rt50aUa+4yrHtO/F5he6l
DtrPZDzW+N3sEt4gBbqVp4nHNVo2O8JGvoaYAM+ASGW7xxQgNNjt+HTqFarDdVCq
MCalceHgzlxWSMY5sCs2xsdJzbc9P0n6dZisByuFZvujMv8QvQ5LZv0s4Ty/XZMK
deU5ziY5SoYlzruHll8UtSbXP4RW9V7hTly01i5zbKxy8gPvDDhjliulYJoVGg5T
DiAOUp7qpbksdrR3fXn8C1LF1+0UcW2yD9mOb3WVAoMj4r9ngxxi0btA1OurZI/Y
BGBeUxQSoAb0tzPUU1FQin0wwTBUC+o/ZGlf1ECkezCPr7CRlpi1e64Ws46/8vt9
sA78u7fLnTl/H4EIeg2qAT98J9AnQxbXncwuoZ5inr/tDxl5ER5zpQK4EfO/H+nC
8j7x3j8kQ/AEs4wEleQYAG6HXFu6GLw2cuhcKGnqW9cEI9xjiqDBfWWC1Vigkvou
ScolTguT0u0d5d0wNQqPtcEyaGcYYDMZfpzO81bU/fFqtg++/i1gKXKPy77KdpV1
s9/RkrCv7tx2Dy5kcXpi
=xUhi
-----END PGP SIGNATURE-----
Merge tag 'acpica-4.1-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm
Pull ACPICA updates from Rafael Wysocki:
"This updates the kernel's ACPICA code to upstream revision 20150410
and adds a fix for a GPE handling regression introduced during the
3.19 cycle on top of that.
Included are two stable-candidate bug fixes (one of them fixing a 3.16
regression), multiple other fixes and a bunch of cleanups.
Specifics:
- Fix for a GPE handling regression on Dell Latitude D600 that caused
GPE signaling to stop working on that machine, which appears to be
due to a hardware glitch, but it used to work and it can be made
work again in a relativly straightforward way (Rafael J Wysocki).
- Fix for a mutex unlock regression related to the handling of ACPI
tables introduced during the 3.16 development cycle (Octavian
Purdila).
- _REV modification to always return 2 which has been done by all
versions of Windows since NT and the firmware people started to use
it to distinguish between OSes in their AML and do some silly and
wrong things on that basis (Bob Moore).
- Fixes and cleanups related to the acpi_physicall_address data type
including one stable-candidate fix for an issue occasionally
occuring on 64-bit machines running 32-bit kernels where using
offsets provided by the firmware may lead to address overflows (Lv
Zheng).
- External() opcode support infrastructure needed for recompiling
disassembled ACPI tables in some cases including interpreter
modification to ignore that opcode (Bob Moore).
- Support for the "Windows 2015" string in _OSI (Bob Moore).
- GPE debug interface change to return values read from hardware
registers (Lv Zheng).
- Removal of the __DATE__ macro usage in tools (Rasmus Villemoes).
- Assorted minor fixes and cleanups (Lv Zheng, Rickard Strandqvist,
Bob Moore)"
* tag 'acpica-4.1-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm: (32 commits)
ACPICA: Store GPE register enable masks upfront
ACPICA: Update version to 20150410.
ACPICA: Fix a couple issues with the local printf module.
ACPICA: Disassembler: Some cleanup of the table dump module.
ACPICA: iASL: Add support for MSDM ACPI table.
ACPICA: Update for SLIC ACPI table.
ACPICA: Add "//" before ascii output of buffers.
ACPICA: Remove unused internal AML opcode.
ACPICA: Permanently set _REV to the value '2'.
ACPICA: Add "Windows 2015" string to _OSI support.
ACPICA: Add infrastructure for External() opcode.
ACPICA: iASL: Enhancement for constant folding.
ACPICA: iASL/Disassembler: Add option to assume table contains valid AML.
ACPICA: Update AML Debugger global variables.
ACPICA: Update Resource descriptor dump module.
ACPICA: Fix a sscanf format string.
ACPICA: Casting changes around acpi_physical_address/acpi_size.
ACPICA: Resources: Correct conditional compilation definitions.
ACPICA: Utilities: Correct conditional compilation definitions.
ACPICA: Tables: Move an iasl specific table function to iasl source file.
...
- Generic PM domains support update including new PM domain
callbacks to handle device initialization better (Russell King,
Rafael J Wysocki, Kevin Hilman).
- Unified device properties API update including a new mechanism
for accessing data provided by platform initialization code
(Rafael J Wysocki, Adrian Hunter).
- ARM cpuidle update including ARM32/ARM64 handling consolidation
(Daniel Lezcano).
- intel_idle update including support for the Silvermont Core in
the Baytrail SOC and for the Airmont Core in the Cherrytrail and
Braswell SOCs (Len Brown, Mathias Krause).
- New cpufreq driver for Hisilicon ACPU (Leo Yan).
- intel_pstate update including support for the Knights Landing
chip (Dasaratharaman Chandramouli, Kristen Carlson Accardi).
- QorIQ cpufreq driver update (Tang Yuantian, Arnd Bergmann).
- powernv cpufreq driver update (Shilpasri G Bhat).
- devfreq update including Tegra support changes (Tomeu Vizoso,
MyungJoo Ham, Chanwoo Choi).
- powercap RAPL (Running-Average Power Limit) driver update
including support for Intel Broadwell server chips (Jacob Pan,
Mathias Krause).
- ACPI device enumeration update related to the handling of the
special PRP0001 device ID allowing DT-style 'compatible' property
to be used for ACPI device identification (Rafael J Wysocki).
- ACPI EC driver update including limited _DEP support (Lan Tianyu,
Lv Zheng).
- ACPI backlight driver update including a new mechanism to allow
native backlight handling to be forced on non-Windows 8 systems
and a new quirk for Lenovo Ideapad Z570 (Aaron Lu, Hans de Goede).
- New Windows Vista compatibility quirk for Sony VGN-SR19XN (Chen Yu).
- Assorted ACPI fixes and cleanups (Aaron Lu, Martin Kepplinger,
Masanari Iida, Mika Westerberg, Nan Li, Rafael J Wysocki).
- Fixes related to suspend-to-idle for the iTCO watchdog driver and
the ACPI core system suspend/resume code (Rafael J Wysocki, Chen Yu).
- PM tracing support for the suspend phase of system suspend/resume
transitions (Zhonghui Fu).
- Configurable delay for the system suspend/resume testing facility
(Brian Norris).
- PNP subsystem cleanups (Peter Huewe, Rafael J Wysocki).
/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
iQIcBAABCAAGBQJVLbO+AAoJEILEb/54YlRx5N4QAJXsmEW1FL2l6mMAyTQkEsVj
nbqjF9I6aJgYM9+i8GKaZJxpN17SAZ7Ii7aCAXjPwX8AvjT70+gcZr+KDWtPir61
B75VNVEcUYOR4vOF5Z6rQcQMlhGPkfMOJYXFMahpOG6DdPbVh1x2/tuawfc6IC0V
a6S/fln6WqHrXQ+8swDSv1KuZsav6+8AQaTlNUQkkuXdY9b3k/3xiy5C2K26APP8
x1B39iAF810qX6ipnK0gEOC3Vs29dl7hvNmgOVmmkBGVS7+pqTuy5n1/9M12cDRz
78IQ7DXB0NcSwr5tdrmGVUyH0Q6H9lnD3vO7MJkYwKDh5a/2MiBr2GZc4KHDKDWn
E1sS27f1Pdn9qnpWLzTcY+yYNV3EEyre56L2fc+sh+Xq9sNOjUah+Y/eAej/IxYD
XYRf+GAj768yCJgNP+Y3PJES/PRh+0IZ/dn5k0Qq2iYvc8mcObyG6zdQIvCucv/i
70uV1Z2GWEb31cI9TUV8o5GrMW3D0KI9EsCEEpiFFUnhjNog3AWcerGgFQMHxu7X
ZnNSzudvek+XJ3NtpbPgTiJAmnMz8bDvBQm3G1LUO2TQdjYTU6YMUHsfzXs8DL6c
aIMWO4stkVuDtWrlT/hfzIXepliccyXmSP6sbH+zNNCepulXe5C4M2SftaDi4l/B
uIctXWznvHoGys+EFL+v
=erd3
-----END PGP SIGNATURE-----
Merge tag 'pm+acpi-4.1-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm
Pull power management and ACPI updates from Rafael Wysocki:
"These are mostly fixes and cleanups all over, although there are a few
items that sort of fall into the new feature category.
First off, we have new callbacks for PM domains that should help us to
handle some issues related to device initialization in a better way.
There also is some consolidation in the unified device properties API
area allowing us to use that inferface for accessing data coming from
platform initialization code in addition to firmware-provided data.
We have some new device/CPU IDs in a few drivers, support for new
chips and a new cpufreq driver too.
Specifics:
- Generic PM domains support update including new PM domain callbacks
to handle device initialization better (Russell King, Rafael J
Wysocki, Kevin Hilman)
- Unified device properties API update including a new mechanism for
accessing data provided by platform initialization code (Rafael J
Wysocki, Adrian Hunter)
- ARM cpuidle update including ARM32/ARM64 handling consolidation
(Daniel Lezcano)
- intel_idle update including support for the Silvermont Core in the
Baytrail SOC and for the Airmont Core in the Cherrytrail and
Braswell SOCs (Len Brown, Mathias Krause)
- New cpufreq driver for Hisilicon ACPU (Leo Yan)
- intel_pstate update including support for the Knights Landing chip
(Dasaratharaman Chandramouli, Kristen Carlson Accardi)
- QorIQ cpufreq driver update (Tang Yuantian, Arnd Bergmann)
- powernv cpufreq driver update (Shilpasri G Bhat)
- devfreq update including Tegra support changes (Tomeu Vizoso,
MyungJoo Ham, Chanwoo Choi)
- powercap RAPL (Running-Average Power Limit) driver update including
support for Intel Broadwell server chips (Jacob Pan, Mathias Krause)
- ACPI device enumeration update related to the handling of the
special PRP0001 device ID allowing DT-style 'compatible' property
to be used for ACPI device identification (Rafael J Wysocki)
- ACPI EC driver update including limited _DEP support (Lan Tianyu,
Lv Zheng)
- ACPI backlight driver update including a new mechanism to allow
native backlight handling to be forced on non-Windows 8 systems and
a new quirk for Lenovo Ideapad Z570 (Aaron Lu, Hans de Goede)
- New Windows Vista compatibility quirk for Sony VGN-SR19XN (Chen Yu)
- Assorted ACPI fixes and cleanups (Aaron Lu, Martin Kepplinger,
Masanari Iida, Mika Westerberg, Nan Li, Rafael J Wysocki)
- Fixes related to suspend-to-idle for the iTCO watchdog driver and
the ACPI core system suspend/resume code (Rafael J Wysocki, Chen Yu)
- PM tracing support for the suspend phase of system suspend/resume
transitions (Zhonghui Fu)
- Configurable delay for the system suspend/resume testing facility
(Brian Norris)
- PNP subsystem cleanups (Peter Huewe, Rafael J Wysocki)"
* tag 'pm+acpi-4.1-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm: (74 commits)
ACPI / scan: Fix NULL pointer dereference in acpi_companion_match()
ACPI / scan: Rework modalias creation when "compatible" is present
intel_idle: mark cpu id array as __initconst
powercap / RAPL: mark rapl_ids array as __initconst
powercap / RAPL: add ID for Broadwell server
intel_pstate: Knights Landing support
intel_pstate: remove MSR test
cpufreq: fix qoriq uniprocessor build
ACPI / scan: Take the PRP0001 position in the list of IDs into account
ACPI / scan: Simplify acpi_match_device()
ACPI / scan: Generalize of_compatible matching
device property: Introduce firmware node type for platform data
device property: Make it possible to use secondary firmware nodes
PM / watchdog: iTCO: stop watchdog during system suspend
cpufreq: hisilicon: add acpu driver
ACPI / EC: Call acpi_walk_dep_device_list() after installing EC opregion handler
cpufreq: powernv: Report cpu frequency throttling
intel_idle: Add support for the Airmont Core in the Cherrytrail and Braswell SOCs
intel_idle: Update support for Silvermont Core in Baytrail SOC
PM / devfreq: tegra: Register governor on module init
...
It is reported that ACPI interrupts do not work any more on
Dell Latitude D600 after commit c50f13c672 (ACPICA: Save
current masks of enabled GPEs after enable register writes).
The problem turns out to be related to the fact that the
enable_mask and enable_for_run GPE bit masks are not in
sync (in the absence of any system suspend/resume events)
for at least one GPE register on that machine.
Address this problem by writing the enable_for_run mask into
enable_mask as soon as enable_for_run is updated instead of
doing that only after the subsequent register write has
succeeded. For consistency, update acpi_hw_gpe_enable_write()
to store the bit mask to be written into the GPE register
in enable_mask unconditionally before the write.
Since the ACPI_GPE_SAVE_MASK flag is not necessary any more after
that, drop it along with the symbols depending on it.
Reported-and-tested-by: Jim Bos <jim876@xs4all.nl>
Fixes: c50f13c672 (ACPICA: Save current masks of enabled GPEs after enable register writes)
Cc: 3.19+ <stable@vger.kernel.org> # 3.19+
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
ACPICA commit 6853da4c0a99b49d62d6c58d22956cd6ff5759a9
The following commit has fixed local printf issue in width.prec:
Commit: 3589b8b8af
Subject: ACPICA: Utilities: Fix local printf issue.
But this commit only resets width/precision/quialifier to fix the reported
issue and doesn't fix other states issues. So now we still can see breakage
in format types and integer bases.
This patch resets format type/base states for local printf to fix this
issue. Lv Zheng.
Linux kernel is not affected by this patch as acpi_ut_vsnprintf() hasn't
been enabled in the kernel.
Link: https://github.com/acpica/acpica/commit/6853da4c
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 657dc227672709895df3192fa5ea59a649b9a76f
Updates the dump buffer utility to comment out the ASCII part
of buffer dump. Prevents some tools from getting confused.
Link: https://github.com/acpica/acpica/commit/657dc227
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 3ec867764b079a98d8097d705c9f7b68270c04ec
This patch removes unused AML_INT_STATICSTRING_OP. Lv Zheng.
Link: https://github.com/acpica/acpica/commit/3ec86776
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 7af00219681ab35ebe57d64a9189fd04a5a026d8
Windows uses a value of 2, and has no plans to ever change this. So, _REV is
essentially useless for its primary purpose.
Worse, some BIOS vendors have used the difference in _REV values between
Windows and ACPICA to indicate which one is running.
It has been decided by the ACPI community to deprecate this method, and return
1 for ACPI 1.0 (32-bit integers) and 2 for ACPI 2.0 and greater (both 32-bit
and 64-bit integers.
ACPICA is changed to reflect this.
Link: https://github.com/acpica/acpica/commit/7af00219
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 b293f602a67da478ae0bec129e68bd99787d9908
This change adds this string for Windows 10.
Link: https://github.com/acpica/acpica/commit/b293f602
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 d115fe2ffdab449d6107d58580c5afd0a81d65fe
This change adds the basic low-level infrastructure for the External
AML opcode. The interpreter will simply ignore this op, as the op
is intended for use by the disassembler only.
Note that External() opcode is useful for disassembler, interpreter
can simply ignore it and still return exceptions for unknown control
methods so the kernel part only includes the grammar definition of
External() opcode in order to ignore it but doesn't interpret it.
Link: https://github.com/acpica/acpica/commit/d115fe2f
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 4f9e950d41cd6f6c704d5d6cf518647620d65e99
Add support to fold expressions with a target operand -- these are
folded and converted to a Store operator:
Add (4, 3, INT1) --> Store (7, INT1)
Also supports ASL+ constructs:
INT1 = 4 + 3 --> Store (7, INT1)
Linux kernel is not affected by this patch.
Link: https://github.com/acpica/acpica/commit/4f9e950d
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 f5d2ff3fa05341d9fe27250fcb2e14c7f871432c
For dynamically loaded tables that have unknown ACPI signatures,
this option (-df) forces the disassembler to treat the table as if
it contains valid AML code (like a DSDT or SSDT). Otherwise, the
disassembler will treat the table as an unkown data table and
simply do a hex dump of the table.
Linux kernel is not affected by this patch.
Link: https://github.com/acpica/acpica/commit/f5d2ff3f
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 f65d0e5b880860a6da0c336b7c48139d1469f5b4
- Remove unused variables
- Update to use standard naming/capitalization convention.
Linux kernel is not affected by this patch.
Link: https://github.com/acpica/acpica/commit/f65d0e5b
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 184f3cc4d162a6b6b2005eacd8be2fe55f19a245
- Change global #ifdef to check for ACPI_DEBUGGER only.
- Cleanup some long lines and misaligned code.
Link: https://github.com/acpica/acpica/commit/184f3cc4
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 46dc081e570b1363af1e368980201cbb65c4100f
Update for some recent changes, detected by MSVC and FreeBSD builds.
Link: https://github.com/acpica/acpica/commit/46dc081e
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 f92a08512b0b35dce4a7fc6a73216674a3c2541b
Some conditional compilation definitions are wrong across header and source
files. This patch corrects them for the resources component.
NOTE that a further patch in this patchset cleans up all ACPI_EXEC_APP,
converting them into ACPI_DEBUGGER, including part of this change.
Link: https://github.com/acpica/acpica/commit/f92a0851
Reported-by: Rickard Strandqvist <rickard_strandqvist@spectrumdigital.se>
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 9a5982afbebc56289c4834b5f6dac87e0f04af14
Some conditional compilation definitions are wrong across header and source
files. This patch corrects them for the utilities component.
Link: https://github.com/acpica/acpica/commit/9a5982af
Reported-by: Rickard Strandqvist <rickard_strandqvist@spectrumdigital.se>
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 6eb364d790dd103bd4990f808e0095a421c437cb
acpi_tb_store_table() implements a logic that is only correct to iasl. So it
won't be used by any other utilities except iasl. This function is
complained by the kernel users as an unused function. The best choice to
stop releasing it to the Linux kernel should be moving it to adisasm.c.
ACPI table manager can use both struct acpi_table_desc (direct referencing)
and table index (indirect referencing) as the descriptor to the table, so
acpi_tb_get_next_root_index() is extended to return both of them to allow
maximum usability from the callers. NOTE that indirect referencing is a
design result to meet the boot stage static allocation requirement for the
table descriptors.
This is a linuxized acpi_tb_store_table() removing result, there should be
no functional changes introduced to the Linux kernel by this patch except
the additonal kernel unused argument for acpi_tb_get_next_root_index()
(renamed to acpi_tb_get_next_root_index()). This argument is used in the
ACPICA upstream.
Link: https://github.com/acpica/acpica/commit/6eb364d7
Reported-by: Rickard Strandqvist <rickard_strandqvist@spectrumdigital.se>
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 2a9ebd974aee41391f4b0edcd4f0cc5ee23ec2f8
Remove the function acpi_ut_create_pkg_state_and_push() that is not used anywhere.
This was partially found by using a static code analysis program called cppcheck.
Link: https://github.com/acpica/acpica/commit/2a9ebd97
Signed-off-by: Rickard Strandqvist <rickard_strandqvist@spectrumdigital.se>
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 3d9fb6d1f216a78ad098d3ad23f1304376c2f4ef
The macro __DATE__ and friends is not allowed in the Linux kernel. Also,
including the build time in output doesn't seem to provide any value.
Link: https://github.com/acpica/acpica/commit/3d9fb6d1
Signed-off-by: Rasmus Villemoes <linux@rasmusvillemoes.dk>
Acked-by: David E. Box <david.e.box@linux.intel.com>
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 e25d791e4b3d5b9f4ead298269610cb05f89749a
There is a facility in Linux, developers can obtain GPE and fixed event
status via /sys/firmware/interrupts/. This is implemented using
acpi_get_event_status() and acpi_get_gpe_status(). Recently while debugging some
GPE race issues, it is found that the facility is lacking in the ability to
obtain real hardware register values, the confusing information makes
debugging difficult.
This patch modifies acpi_get_gpe_status() to return EN register values to fix
this gap. Then flags returned from acpi_get_event_status() and
acpi_get_gpe_status() are also cleaned up to reflect this change.
The old ACPI_EVENT_FLAG_SET is carefully kept to avoid regressions. It can
be deleted after we can make sure all its references are removed from OSPM
code. Lv Zheng.
Link: https://github.com/acpica/acpica/commit/e25d791e
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 c70434d4da13e65b6163c79a5aa16b40193631c7
ACPI_MTX_TABLES is acquired and released by the callers of
acpi_tb_install_standard_table() so releasing it in the function itself is
causing the following error in Linux kernel if the table is reloaded:
ACPI Error: Mutex [0x2] is not acquired, cannot release (20141107/utmutex-321)
Call Trace:
[<ffffffff81b0bd48>] dump_stack+0x4f/0x7b
[<ffffffff81546bf5>] acpi_ut_release_mutex+0x47/0x67
[<ffffffff81544357>] acpi_load_table+0x73/0xcb
Link: https://github.com/acpica/acpica/commit/c70434d4
Signed-off-by: Octavian Purdila <octavian.purdila@intel.com>
Signed-off-by: Lv Zheng <lv.zheng@intel.com>
Signed-off-by: Bob Moore <robert.moore@intel.com>
Cc: 3.16+ <stable@vger.kernel.org> # 3.16+
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
ACPICA commit b60612373a4ef63b64a57c124576d7ddb6d8efb6
For physical addresses, since the address may exceed 32-bit address range
after calculation, we should use 0x%8.8X%8.8X instead of ACPI_PRINTF_UINT
and ACPI_FORMAT_UINT64() instead of
ACPI_FORMAT_NATIVE_UINT()/ACPI_FORMAT_TO_UINT().
This patch also removes above replaced macros as there are no users.
This is a preparation to switch acpi_physical_address to 64-bit on 32-bit
kernel builds.
Link: https://github.com/acpica/acpica/commit/b6061237
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 7f06739db43a85083a70371c14141008f20b2198
For physical addresses, since the address may exceed 32-bit address range
after calculation, we should use %8.8X%8.8X (see ACPI_FORMAT_UINT64()) to
convert the %p formats.
This is a preparation to switch acpi_physical_address to 64-bit on 32-bit
kernel builds.
Link: https://github.com/acpica/acpica/commit/7f06739d
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 154f6d074dd38d6ebc0467ad454454e6c5c9ecdf
There are code pieces converting pointers using "(acpi_physical_address) x"
or "ACPI_CAST_PTR (t, x)" formats, this patch cleans up them.
Known issues:
1. Cleanup of "(ACPI_PHYSICAL_ADDRRESS) x" for a table field
For the conversions around the table fields, it is better to fix it with
alignment also fixed. So this patch doesn't modify such code. There
should be no functional problem by leaving them unchanged.
Link: https://github.com/acpica/acpica/commit/154f6d07
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 c327986430b7eb170c17d0f45735fe71bb62a810
The conversion converts an acpi_physical_address to acpi_physical_address,
this patch thus removes such useless conversion.
Link: https://github.com/acpica/acpica/commit/c3279864
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 7d9fd64397d7c38899d3dc497525f6e6b044e0e3
OSPMs like Linux expect an acpi_physical_address returning value from
acpi_find_root_pointer(). This triggers warnings if sizeof (acpi_size) doesn't
equal to sizeof (acpi_physical_address):
drivers/acpi/osl.c:275:3: warning: passing argument 1 of 'acpi_find_root_pointer' from incompatible pointer type [enabled by default]
In file included from include/acpi/acpi.h:64:0,
from include/linux/acpi.h:36,
from drivers/acpi/osl.c:41:
include/acpi/acpixf.h:433:1: note: expected 'acpi_size *' but argument is of type 'acpi_physical_address *'
This patch corrects acpi_find_root_pointer().
Link: https://github.com/acpica/acpica/commit/7d9fd643
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>
This patch reduces source code differences between the Linux kernel and the
ACPICA upstream so that the linuxized ACPICA 20150410 release can be
applied with reduced human intervention.
Signed-off-by: Lv Zheng <lv.zheng@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Lv Zheng