| Age | Commit message (Collapse) | Author |
|---|
|
If the ACPI tables change as a result of a dinamically loaded table
and a bus rescan is required the enumeration/visited flag are not
consistent.
I2C/SPI are not directly enumerated in acpi_bus_attach(), however
the visited flag is set. This makes it impossible to check if an
ACPI device has already been enumerated by the I2C and SPI
subsystems. To fix this issue we only set the visited flags if
the device is not I2C or SPI.
With this change we also need to remove setting visited to false
from acpi_bus_attach(), otherwise if we rescan already enumerated
I2C/SPI devices we try to re-enumerate them.
Note that I2C/SPI devices can be enumerated either via a scan handler
(when using PRP0001) or via regular device_attach(). In either case
the flow goes through acpi_default_enumeration() which makes it the
ideal place to mark the ACPI device as enumerated.
Signed-off-by: Octavian Purdila <octavian.purdila@intel.com>
Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
There is an order issue in ec_remove_handlers() that acpi_ec_stop()
is called before removing the operation region handler. That is
incorrect, because the operation region handler removal triggers
_REG(DISCONNECT) which may result in new EC transactions to carry
out.
That existing issue has been triggered by the following commit:
Commit: dcf15cbded656a12335bc4151f3f75f10080a375
Subject: ACPI / EC: Fix a boot EC regresion by restoring boot EC
which changed the driver to call ec_remove_handlers() after invoking
_REG(CONNECT), so the issue has become visible.
Fixes: dcf15cbded65 (ACPI / EC: Fix a boot EC regresion by restoring boot EC)
Link: https://bugzilla.kernel.org/show_bug.cgi?id=102421
Reported-and-tested-by: Wolfram Sang <wsa@the-dreams.de>
Reported-by: Nicholas <nkudriavtsev@gmail.com>
Signed-off-by: Lv Zheng <lv.zheng@intel.com>
[ rjw: Changelog ]
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
In preparation for generically mapping flush hint addresses for both the
BLK and PMEM use case, provide a generic / reference counted mapping
api. Given the fact that a dimm may belong to multiple regions (PMEM
and BLK), the flush hint addresses need to be held valid as long as any
region associated with the dimm is active. This is similar to the
existing BLK-region case where multiple BLK-regions may share an
aperture mapping. Up-level this shared / reference-counted mapping
capability from the nfit driver to a core nvdimm capability.
This eliminates the need for the nd_blk_region.disable() callback. Note
that the removal of nfit_spa_map() and related infrastructure is
deferred to a later patch.
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
|
|
We were needlessly converting nfit_mem_init() errors to -ENOMEM.
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
|
|
Before enabling use of flush hints for pmem regions, we need to make
sure they are always associated. Move the initialization of nfit_flush
out of the block-window specific init path to the general init path.
Cc: Ross Zwisler <ross.zwisler@linux.intel.com>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
|
|
* acpica-fixes:
ACPICA: Namespace: Fix namespace/interpreter lock ordering
* acpi-pci-fixes:
ACPI,PCI,IRQ: separate ISA penalty calculation
Revert "ACPI, PCI, IRQ: remove redundant code in acpi_irq_penalty_init()"
ACPI,PCI,IRQ: factor in PCI possible
* acpi-debug-fixes:
ACPI / debugger: Fix regression introduced by IS_ERR_VALUE() removal
|
|
If devm_add_action() fails, we are explicitly calling the cleanup to free
the resources allocated. Lets use the helper devm_add_action_or_reset()
and return directly in case of error, since the cleanup function
has been already called by the helper if there was any error.
Signed-off-by: Vikas C Sajjan <vikas.cha.sajjan@hpe.com>
Reviewed-by: Johannes Thumshirn <jthumshirn@suse.de>
Reviewed-by: Lee, Chun-Yi <jlee@suse.com>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
|
|
This patch adds support for platform initited graceful shutdown as
described in sections 5.6.6(Table-143) and 6.3.5.1 of ACPI 6.1 spec
The OSPM will get a graceful shutdown request via a Notify operator
on \_SB device with a value of 0x81 per section 5.6.6. Following the
shutdown request from platform the OSPM needs to follow the
processing sequence as described in section 6.2.5.1.
v3
* Switched to regular work with delays from delayed work
* Dropped changes to actypes.h
* Small style changes
v2
* Switched from standalone driver to a simple notify handler
v1
* Initial
Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>
Signed-off-by: Prashanth Prakash <pprakash@codeaurora.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
ACPI 6.0 introduces a new table STAO to list the devices which are used
by Xen and can't be used by Dom0. On Xen virtual platforms, the physical
UART is used by Xen. So here it hides UART from Dom0.
CC: "Rafael J. Wysocki" <rjw@rjwysocki.net> (supporter:ACPI)
CC: Len Brown <lenb@kernel.org> (supporter:ACPI)
CC: linux-acpi@vger.kernel.org (open list:ACPI)
Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
In acpi_subsystem_init(), function acpi_enable_subsystem() is
called to do the real job. However with different flags passed to
acpi_enable_subsystem(), different code is executed.
In acpi_subsystem_init(), with "~ACPI_NO_ACPI_ENABLE" passed in, it
will only switch over the platform to the ACPI mode. The remaining
part of acpi_enable_subsystem() is done when acpi_bus_init() is
called.
So the comments above acpi_subsystem_init() is not exact, change it
here.
Signed-off-by: Baoquan He <bhe@redhat.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
The FIFO unlocking mechanism in acpi_dbg has been broken by the
following commit:
Commit: 287980e49ffc0f6d911601e7e352a812ed27768e
Subject: remove lots of IS_ERR_VALUE abuses
It converted !IS_ERR_VALUE(ret) into !ret which was not entirely
correct. Fix the regression by taking ret > 0 into account too as
appropriate.
Fixes: 287980e49ffc (remove lots of IS_ERR_VALUE abuses)
Signed-off-by: Lv Zheng <lv.zheng@intel.com>
[ rjw: Simplifications, changelog & subject massage ]
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
There is a lock order issue in acpi_load_tables(). The namespace lock
is held before holding the interpreter lock.
With ACPI_MUTEX_DEBUG enabled in the kernel, this is printed to the
log during boot:
[ 0.885699] ACPI Error: Invalid acquire order: Thread 405884224 owns [ACPI_MTX_Namespace], wants [ACPI_MTX_Interpreter] (20160422/utmutex-263)
[ 0.885881] ACPI Error: Could not acquire AML Interpreter mutex (20160422/exutils-95)
[ 0.893846] ACPI Error: Mutex [0x0] is not acquired, cannot release (20160422/utmutex-326)
[ 0.894019] ACPI Error: Could not release AML Interpreter mutex (20160422/exutils-133)
The issue has been introduced by the following commit:
Commit: 2f38b1b16d9280689e5cfa47a4c50956bf437f0d
ACPICA Commit: bfe03ffcde8ed56a7eae38ea0b188aeb12f9c52e
Subject: ACPICA: Namespace: Fix a regression that MLC support triggers
dead lock in dynamic table loading
Which fixed a deadlock issue for acpi_ns_load_table() in
acpi_ex_add_table() but didn't take care of the lock order in
acpi_ns_load_table() correctly.
Originally (before the above commit), ACPICA used the
namespace/interpreter locks in the following 2 key code
paths:
1. Table loading:
acpi_ns_load_table
L(Namespace)
acpi_ns_parse_table
acpi_ns_one_complete_parse
U(Namespace)
2. Object evaluation:
acpi_ns_evaluate
L(Interpreter)
acpi_ps_execute_method
U(Interpreter)
acpi_ns_load_table
L(Namespace)
U(Namespace)
acpi_ev_initialize_region
L(Namespace)
U(Namespace)
address_space.setup
L(Namespace)
U(Namespace)
address_space.handler
L(Namespace)
U(Namespace)
acpi_os_wait_semaphore
acpi_os_acquire_mutex
acpi_os_sleep
L(Interpreter)
U(Interpreter)
During runtime, while acpi_ns_evaluate is called, the lock order is
always Interpreter -> Namespace.
In turn, the problematic commit acquires the locks in the following
order:
3. Table loading:
acpi_ns_load_table
L(Namespace)
acpi_ns_parse_table
L(Interpreter)
acpi_ns_one_complete_parse
U(Interpreter)
U(Namespace)
To fix the lock order issue, move the interpreter lock to
acpi_ns_load_table() to ensure the lock order correctness:
4. Table loading:
acpi_ns_load_table
L(Interpreter)
L(Namespace)
acpi_ns_parse_table
acpi_ns_one_complete_parse
U(Namespace)
U(Interpreter)
However, this doesn't fix the current design issues related to the
namespace lock. For example, we can notice that in acpi_ns_evaluate(),
outside of acpi_ns_load_table(), the namespace objects may be created
by the named object creation control methods. And the creation of
the method-owned namespace objects are not locked by the namespace
lock. This patch doesn't try to fix such kind of existing issues.
Fixes: 2f38b1b16d92 (ACPICA: Namespace: Fix a regression that MLC support triggers dead lock in dynamic table loading)
Signed-off-by: Lv Zheng <lv.zheng@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
Our Windows probe result shows that EC._REG is evaluated after evaluating
all _INI/_STA control methods.
With boot EC always switched in acpi_ec_dsdt_probe(), we can see that as
long as there is no EC opregion accesses in the MLC (module level code, AML
code out of any control methods) and in _INI/_STA, there is no need to make
sure that ECDT must be correct.
Bugs of 9399/12461 were reported against an order issue that BAT0/1._STA
evaluations contain EC accesses while the ECDT setting is wrong.
>From the acpidump output posted on bug 9399, we can see that it is actually
a different issue. In this table, if EC._REG is not executed, EC accesses
will be done in a platform specific manner. As we've already ensured not to
execute EC._REG during the eary stage, we can remove the quirks for bug
9399.
From the acpidump output posted on bug 12461, we can see that it still
needs the quirk. In this table, EC._REG flags a named object whose default
value is One, thus BAT1._STA surely should invoke EC accesses whatever we
invoke EC._REG or not. We have to keep the quirk for it before we can root
cause the issue.
Signed-off-by: Lv Zheng <lv.zheng@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
Failure handling of the boot EC code is not tidy. This patch cleans
them up with acpi_ec_alloc().
This patch also changes acpi_ec_dsdt_probe(), always switches the
boot EC from the ECDT one to the DSDT one in this function.
Signed-off-by: Lv Zheng <lv.zheng@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
Since commit 103544d86976 (ACPI,PCI,IRQ: reduce resource requirements)
the penalty values are calculated on the fly rather than at boot time.
This works fine for PCI interrupts but not so well for ISA interrupts.
The information on whether or not an ISA interrupt is in use is not
available to the pci_link.c code directly. That information is
obtained from the outside via acpi_penalize_isa_irq(). [If its
"active" argument is true, then the IRQ is in use by ISA.]
Since the current code relies on PCI Link objects for determination
of penalties, we are factoring in the PCI penalty twice after
acpi_penalize_isa_irq() function is called.
To avoid that, limit the newly added functionality to just PCI
interrupts so that old behavior is still maintained.
Fixes: 103544d86976 (ACPI,PCI,IRQ: reduce resource requirements)
Signed-off-by: Sinan Kaya <okaya@codeaurora.org>
Tested-by: Wim Osterholt <wim@djo.tudelft.nl>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
Trying to make the ISA and PCI init functionality common turned out
to be a bad idea, because the ISA path depends on external
functionality.
Restore the previous behavior and limit the refactoring to PCI
interrupts only.
Fixes: 1fcb6a813c4f "ACPI,PCI,IRQ: remove redundant code in acpi_irq_penalty_init()"
Signed-off-by: Sinan Kaya <okaya@codeaurora.org>
Tested-by: Wim Osterholt <wim@djo.tudelft.nl>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
The change introduced in commit 103544d86976 (ACPI,PCI,IRQ: reduce
resource requirements) omitted the initially applied PCI_POSSIBLE
penalty when the IRQ is active.
Incorrect calculation of the penalty leads the ACPI code to assigning
a wrong interrupt number to a PCI INTx interrupt.
This would not be as bad as it sounds in theory. It would just cause
the interrupts to be shared and result in performance penalty.
However, some drivers (like the parallel port driver) don't like
interrupt sharing and in the above case they will causes all of
the PCI drivers wanting to share the interrupt to be unable to
request it.
The issue has not been caught in testing because the behavior is
platform-specific and depends on the peripherals ending up sharing
the IRQ and their drivers.
Before the above commit the code would add the PCI_POSSIBLE value
divided by the number of possible IRQ users to the IRQ penalty
during initialization.
Later in that code path, if the IRQ is chosen as the active IRQ or
if it is used by ISA; additional penalties are added.
Fixes: 103544d86976 (ACPI,PCI,IRQ: reduce resource requirements)
Signed-off-by: Sinan Kaya <okaya@codeaurora.org>
Tested-by: Wim Osterholt <wim@djo.tudelft.nl>
[ rjw: Changelog ]
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm
Pull ACPI fix from Rafael Wysocki:
"Fix an expression in the ACPI PCI IRQ management code added by a
recent commit that overlooked missing parens in it, so the result of
the computation is incorrect in some cases (Sinan Kaya)"
* tag 'acpi-4.7-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm:
ACPI,PCI,IRQ: correct operator precedence
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/nvdimm/nvdimm
Pull libnvdimm fixes from Dan Williams:
"1/ Two regression fixes since v4.6: one for the byte order of a sysfs
attribute (bz121161) and another for QEMU 2.6's NVDIMM _DSM (ACPI
Device Specific Method) implementation that gets tripped up by new
auto-probing behavior in the NFIT driver.
2/ A fix tagged for -stable that stops the kernel from
clobbering/ignoring changes to the configuration of a 'pfn'
instance ("struct page" driver). For example changing the
alignment from 2M to 1G may silently revert to 2M if that value is
currently stored on media.
3/ A fix from Eric for an xfstests failure in dax. It is not
currently tagged for -stable since it requires an 8-exabyte file
system to trigger, and there appear to be no user visible side
effects"
* 'libnvdimm-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/nvdimm/nvdimm:
nfit: fix format interface code byte order
dax: fix offset overflow in dax_io
acpi, nfit: fix acpi_check_dsm() vs zero functions implemented
libnvdimm, pfn, dax: fix initialization vs autodetect for mode + alignment
|
|
The omitted parenthesis prevents the addition operation when
acpi_penalize_isa_irq function is called.
Fixes: 103544d86976 (ACPI,PCI,IRQ: reduce resource requirements)
Signed-off-by: Sinan Kaya <okaya@codeaurora.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
The _PTS control method is defined in the section 7.4.1 of acpi 6.0
spec. The _PTS control method is executed by the OS during the sleep
transition process for S1, S2, S3, S4, and for orderly S5 shutdown.
The _PTS control method provides the BIOS a mechanism for performing
some housekeeping, such as writing the sleep type value to the embedded
controller, before entering the system sleeping state. Note that some
Lenovo Server BIOS use this mechanism to detect reboot event and
prompt user by popped dialog box.
According to section 7.5 of acpi 6.0 spec, _PTS should run after _TTS.
Add a _PTS evaulation to the existing _TTS reboot notifier and change
the notifier name to reflect the fact that it's not for _TTS only any
more.
Signed-off-by: Ocean He <hehy1@lenovo.com>
Signed-off-by: Nagananda Chumbalkar <nchumbalkar@lenovo.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
ACPI/APEI is designed to verifiy/report H/W errors, like Corrected
Error(CE) and Uncorrected Error(UC). It contains four tables: HEST,
ERST, EINJ and BERT. The first three tables have been merged for
a long time, but because of lacking BIOS support for BERT, the
support for BERT is pending until now. Recently on ARM 64 platform
it is has been supported. So here we come.
Under normal circumstances, when a hardware error occurs, kernel will
be notified via NMI, MCE or some other method, then kernel will
process the error condition, report it, and recover it if possible.
But sometime, the situation is so bad, so that firmware may choose to
reset directly without notifying Linux kernel.
Linux kernel can use the Boot Error Record Table (BERT) to get the
un-notified hardware errors that occurred in a previous boot. In this
patch, the error information is reported via printk.
For more information about BERT, please refer to ACPI Specification
version 6.0, section 18.3.1:
http://www.uefi.org/sites/default/files/resources/ACPI_6.0.pdf
The following log is a BERT record after system reboot because of hitting
a fatal memory error:
BERT: Error records from previous boot:
[Hardware Error]: It has been corrected by h/w and requires no further action
[Hardware Error]: event severity: corrected
[Hardware Error]: Error 0, type: recoverable
[Hardware Error]: section_type: memory error
[Hardware Error]: error_status: 0x0000000000000400
[Hardware Error]: physical_address: 0xffffffffffffffff
[Hardware Error]: card: 1 module: 2 bank: 3 row: 1 column: 2 bit_position: 5
[Hardware Error]: error_type: 2, single-bit ECC
[Tomasz Nowicki: Clear error status at the end of error handling]
[Tony: Applied some cleanups suggested by Fu Wei]
[Fu Wei: delete EXPORT_SYMBOL_GPL(bert_disable), improve the code]
Signed-off-by: Huang Ying <ying.huang@intel.com>
Signed-off-by: Tomasz Nowicki <tomasz.nowicki@linaro.org>
Signed-off-by: Chen, Gong <gong.chen@linux.intel.com>
Tested-by: Jonathan (Zhixiong) Zhang <zjzhang@codeaurora.org>
Signed-off-by: Fu Wei <fu.wei@linaro.org>
Tested-by: Tyler Baicar <tbaicar@codeaurora.org>
Reviewed-by: Borislav Petkov <bp@suse.de>
Signed-off-by: Tony Luck <tony.luck@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
Per JEDEC Annex L Release 3 the SPD data is:
Bits 9~5 00 000 = Function Undefined
00 001 = Byte addressable energy backed
00 010 = Block addressed
00 011 = Byte addressable, no energy backed
All other codes reserved
Bits 4~0 0 0000 = Proprietary interface
0 0001 = Standard interface 1
All other codes reserved; see Definitions of Functions
...and per the ACPI 6.1 spec:
byte0: Bits 4~0 (0 or 1)
byte1: Bits 9~5 (1, 2, or 3)
...so a format interface code displayed as 0x301 should be stored in the
nfit as (0x1, 0x3), little-endian.
Cc: Toshi Kani <toshi.kani@hpe.com>
Cc: Rafael J. Wysocki <rjw@rjwysocki.net>
Cc: Robert Moore <robert.moore@intel.com>
Cc: Robert Elliott <elliott@hpe.com>
Link: https://bugzilla.kernel.org/show_bug.cgi?id=121161
Fixes: 30ec5fd464d5 ("nfit: fix format interface code byte order per ACPI6.1")
Fixes: 5ad9a7fde07a ("acpi/nfit: Update nfit driver to comply with ACPI 6.1")
Reported-by: Kristin Jacque <kristin.jacque@intel.com>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
|
|
Fixes compiler warning.
Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
At least some of the Broxtons have a third custom OpRegion
named REGS. This adds handling for it.
Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
When CPPC fails to request a PCC channel, the CPC data is freed
and cpc_desc_ptr points to the invalid data.
Avoid this issue by moving the cpc_desc_ptr assignment after the PCC
channel request.
Signed-off-by: Hoan Tran <hotran@apm.com>
Acked-by: Ashwin Chaugule <ashwin.chaugule@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
* acpica-fixes:
ACPICA: Namespace: Fix deadlock triggered by MLC support in dynamic table loading
|
|
QEMU 2.6 implements nascent support for nvdimm DSMs. Depending on
configuration it may only implement the function0 dsm to indicate that
no other DSMs are available. Commit 31eca76ba2fc "nfit, libnvdimm:
limited/whitelisted dimm command marshaling mechanism" breaks QEMU, but
QEMU is spec compliant. Per the spec the way to indicate that no
functions are supported is:
If Function Index is zero, the return is a buffer containing one bit
for each function index, starting with zero. Bit 0 indicates whether
there is support for any functions other than function 0 for the
specified UUID and Revision ID. If set to zero, no functions are
supported (other than function zero) for the specified UUID and
Revision ID.
Update the nfit driver to determine the family (interface UUID) without
requiring the implementation to define any other functions, i.e.
short-circuit acpi_check_dsm() to succeed per the spec. The nfit driver
appears to be the only user passing funcs==0 to acpi_check_dsm(), so
this behavior change of the common routine should be limited to the
probing done by the nfit driver.
Cc: Len Brown <lenb@kernel.org>
Cc: Jerry Hoemann <jerry.hoemann@hpe.com>
Acked-by: "Rafael J. Wysocki" <rafael@kernel.org>
Fixes: 31eca76ba2fc ("nfit, libnvdimm: limited/whitelisted dimm command marshaling mechanism")
Reported-by: Xiao Guangrong <guangrong.xiao@linux.intel.com>
Tested-by: Xiao Guangrong <guangrong.xiao@linux.intel.com>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
|
|
This patch adds operation region driver for Intel BXT WhiskeyCove
PMIC. The register mapping is done as per the BXT WC data sheet.
Signed-off-by: Ajay Thomas <ajay.thomas.david.rajamanickam@intel.com>
Signed-off-by: Bin Gao <bin.gao@intel.com>
Reviewed-by: Aaron Lu <aaron.lu@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
Issue description: On some pmics, the policy enable for thermal alerts
refers to different bit fields of the same registers, whereas on other
pmics, the policy enable refers to the same bit field on different
registers. Previous implementation did not provide the flexibility for
supporting the first approach.
Solution: Modified the policy enable function to take bit field as well.
The use of bit field is left to the pmic specific opregion driver.
Signed-off-by: Yegnesh Iyer <yegnesh.s.iyer@intel.com>
Signed-off-by: Bin Gao <bin.gao@intel.com>
Reviewed-by: Aaron Lu <aaron.lu@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
It is absolutely unfriendly when one sees this:
# modprobe einj
modprobe: ERROR: could not insert 'einj': No such device
without anything in dmesg to tell one why the load failed.
Beef up the error handling of the init function to be more user-friendly
when the load fails.
Signed-off-by: Borislav Petkov <bp@suse.de>
Acked-by: Tony Luck <tony.luck@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
... and remove it from the pr_* calls.
Signed-off-by: Borislav Petkov <bp@suse.de>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
Based on 8.4.7.1 section of ACPI 6.1 specification, if the platform
supports CPPC, the _CPC object must exist under all processor objects.
If cpc_desc_ptr pointer is invalid on any CPUs, acpi_get_psd_map()
should return error and CPPC cpufreq driver can not be registered.
Signed-off-by: Hoan Tran <hotran@apm.com>
Reviewed-by: Prashanth Prakash <pprakash@codeaurora.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
acpi_print_osc_error() basically duplicates the functionalit of
acpi_handle_debug(), so use that one in there.
While at it, convert the explicit KERN_DEBUG prints to pr_debug()
(and apply it to continuation messages too).
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
alloc_workqueue replaces deprecated create_workqueue().
A dedicated workqueue has been used since the workqueue
acpi_thermal_pm_queue with workitem &tz->thermal_check_work
(maps to acpi_thermal_check_fn), is involved in thermal zone polling.
Wallclock time is actually important and getting delayed in handling
critical temperature event can actually lead to unnecessary hardware
damage. So while this is not used during memory reclaim, we still want
forward progress guarantee and be generally snappy in servicing it.
Hence, WQ_MEM_RECLAIM and WQ_HIGHPRI have been used here.
Since there are only a fixed number of work items, explicit concurrency
limit is unnecessary here.
Signed-off-by: Bhaktipriya Shridhar <bhaktipriya96@gmail.com>
Acked-by: Tejun Heo <tj@kernel.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
Linux userspace (systemd-logind) keeps on rechecking lid state when the
lid state is closed. If it failed to update the lid state to open after
boot/resume, the system suspending right after the boot/resume could be
resulted.
Graphics drivers also use the lid notifications to implment
MODESET_ON_LID_OPEN option.
Before the situation is improved from the userspace and from the graphics
driver, users can simply configure ACPI button driver to send initial
"open" lid state using button.lid_init_state=open to avoid such kind of
issues.
And our ultimate target should be making button.lid_init_state=ignore
the default behavior. This patch implements the 2 options and keep the
old behavior (button.lid_init_state=method).
Link: https://lkml.org/2016/3/7/460
Link: https://github.com/systemd/systemd/issues/2087
Signed-off-by: Lv Zheng <lv.zheng@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
(Correct a wrong macro usage.)
This patch simplies the code by merging some redundant code.
No functional changes.
Signed-off-by: Lv Zheng <lv.zheng@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
The _LID control method's initial returning value is not reliable.
The _LID control method is described to return the "current" lid state.
However the word of "current" has ambiguity, many BIOSen return the lid
state upon the last lid notification instead of returning the lid state
upon the last _LID evaluation. There won't be difference when the _LID
control method is evaluated during the runtime, the problem is its initial
returning value. When the BIOSen implement this control method with cached
value, the initial returning value is likely not reliable. There are simply
so many examples retuning "close" as initial lid state (Link 1), sending
this state to the userspace causes suspending right after booting/resuming.
Since the lid state is implemented by the BIOSen, the kernel lid driver has
no idea how it can be correct, this patch stops sending the initial lid
state to the userspace to try to avoid sending the wrong lid state to the
userspace to trigger such kind of wrong suspending. This actually reverts
the following commit introduced for fixing a Novell bug:
Commit: 23de5d9ef2a4bbc4f733f58311bcb7cf6239c813
Subject: ACPI: button: send initial lid state after add and resume
Link: https://bugzilla.kernel.org/show_bug.cgi?id=89211
Link: https://bugzilla.kernel.org/show_bug.cgi?id=106151
Link: https://bugzilla.kernel.org/show_bug.cgi?id=106941
Link: https://bugzilla.novell.com/show_bug.cgi?id=326814
Signed-off-by: Lv Zheng <lv.zheng@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
Remove the dbg macro and debug module parameter and use
the generic kernel facility.
Trivially reduces defconfig object size on x86-64
$ size drivers/acpi/pci_slot.o*
text data bss dec hex filename
880 752 4 1636 664 drivers/acpi/pci_slot.o.new
935 752 5 1692 69c drivers/acpi/pci_slot.o.old
Signed-off-by: Joe Perches <joe@perches.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
Use generic pr_<level> functions with pr_fmt for info and err.
This also reduces object size a trivial bit:
$ size drivers/acpi/pci_slot.o*
text data bss dec hex filename
935 752 5 1692 69c drivers/acpi/pci_slot.o.new
1027 752 5 1784 6f8 drivers/acpi/pci_slot.o.old
Miscellanea:
o Remove unnecessary OOM message as k.alloc functions get a generic
stack dump on OOM
o Remove unnecessary embedded prefix from a dbg() message
Signed-off-by: Joe Perches <joe@perches.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
Some system supports hybrid graphics and its discrete VGA
does not have any connectors and therefore has no _DOD method.
Signed-off-by: Alex Hung <alex.hung@canonical.com>
Reviewed-by: Aaron Lu <aaron.lu@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
Add Thinkpad X201 Tablet to the video_detect_force_video blacklist.
Signed-off-by: Ralf Gerbig <rge@quengel.org>
[ rjw : Changelog ]
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
Add function needed for cpu to node mapping, and enable ACPI based
NUMA for ARM64 in Kconfig
Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
Signed-off-by: Robert Richter <rrichter@cavium.com>
[david.daney@cavium.com added ACPI_NUMA default to y for ARM64]
Signed-off-by: David Daney <david.daney@cavium.com>
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
We want to use the table upgrade feature in ARM64.
Introduce a new configuration option that allows that.
Signed-off-by: Aleksey Makarov <aleksey.makarov@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
The constant that defines max phys address where the new upgraded
ACPI table should be allocated is arch-specific. Move it to
<asm/acpi.h>
Signed-off-by: Aleksey Makarov <aleksey.makarov@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
Refer initrd_start, initrd_end directly from drivers/acpi/tables.c.
This allows to use the table upgrade feature in architectures
other than x86. Also this simplifies header files.
The patch renames acpi_table_initrd_init() to acpi_table_upgrade()
(what reflects the purpose of the function) and removes the unneeded
wraps early_acpi_table_init() and early_initrd_acpi_init().
Signed-off-by: Aleksey Makarov <aleksey.makarov@linaro.org>
Acked-by: Lv Zheng <lv.zheng@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
The new memory allocated in acpi_table_initrd_init() is used to
copy the upgraded tables to it. So it should be mapped with
early_memunmap() instead of early_ioremap().
This is critical for ARM.
Signed-off-by: Aleksey Makarov <aleksey.makarov@linaro.org>
Acked-by: Lv Zheng <lv.zheng@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
loading
The new module-level code (MLC) approach invokes MLC on the per-table
basis, but the dynamic loading support of this is incorrect because
of the lock order:
acpi_ns_evaluate
acpi_ex_enter_intperter
acpi_ns_load_table (triggered by Load opcode)
acpi_ns_exec_module_code_list
acpi_ex_enter_intperter
The regression is introduced by the following commit:
Commit: 2785ce8d0da1cac9d8f78615e116cf929e9a9123
ACPICA Commit: 071eff738c59eda1792ac24b3b688b61691d7e7c
Subject: ACPICA: Add per-table execution of module-level code
This patch fixes this regression by unlocking the interpreter lock
before invoking MLC. However, the unlocking is done to the
acpi_ns_load_table(), in which the interpreter lock should be locked
by acpi_ns_parse_table() but it wasn't.
Fixes: 2785ce8d0da1 (ACPICA: Add per-table execution of module-level code)
Reported-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Tested-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Lv Zheng <lv.zheng@intel.com>
Cc: 4.5+ <stable@vger.kernel.org> # 4.5+
[ rjw : Subject ]
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
Add the Microsoft _DSM command set to the white list of NVDIMM command
sets.
This command set is documented at:
https://msdn.microsoft.com/library/windows/hardware/mt604741
Cc: Pavel Machek <pavel@ucw.cz>
[pavel: fix up braces]
Signed-off-by: Stuart Hayes <stuart.w.hayes@gmail.com>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
|
|
* acpica-fixes:
Revert "ACPICA: ACPI 2.0, Hardware: Add access_width/bit_offset support for acpi_hw_write()"
|
