linux/drivers/acpi, branch v4.7

Merge branch 'libnvdimm-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/nvdimm/nvdimm

2016-07-23T03:07:37Z

Pull libnvdimm fix from Dan Williams: "This contains a regression fix for a problem that was introduced in v4.7-rc6. In 4.7-rc1 we introduced auto-probing for the ACPI DSM (device- specific-method) format that the platform firmware implements for nvdimm devices. We initially fixed a regression in probing the QEMU DSM implementation by making acpi_check_dsm() tolerant of the way QEMU reports the "0 DSMs supported" condition. However, that broke HPE platforms since that tolerance caused the driver to mistakenly match the 1-zero-byte response those platforms give to "unknown" commands. Instead, we simply make the driver tolerant of not finding any supported DSMs. This has been tested to work with both QEMU and HPE platforms. This commit has appeared in a -next release with no reported issues" * 'libnvdimm-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/nvdimm/nvdimm: nfit: make DIMM DSMs optional

nfit: make DIMM DSMs optional

2016-07-19T19:32:39Z

Commit 4995734e973a "acpi, nfit: fix acpi_check_dsm() vs zero functions implemented" attempted to fix a QEMU regression by supporting its usage of a zero-mask as a valid response to a DSM-family probe request. However, this behavior breaks HP platforms that return a zero-mask by default causing the probe to misidentify the DSM-family. Instead, the QEMU regression can be fixed by simply not requiring the DSM family to be identified. This effectively reverts commit 4995734e973a, and removes the DSM requirement from the init path. Cc: "Rafael J. Wysocki" Cc: Xiao Guangrong Cc: Linda Knippers Fixes: 4995734e973a ("acpi, nfit: fix acpi_check_dsm() vs zero functions implemented") Reported-by: Jerry Hoemann Tested-by: Jerry Hoemann Signed-off-by: Dan Williams

Merge branches 'acpica-fixes' and 'acpi-ec-fixes'

2016-07-12T20:03:14Z

* acpica-fixes: Revert "ACPI 2.0 / AML: Improve module level execution by moving the If/Else/While execution to per-table basis" Revert "ACPICA: Namespace: Fix deadlock triggered by MLC support in dynamic table loading" Revert "ACPICA: Namespace: Fix namespace/interpreter lock ordering" * acpi-ec-fixes: ACPI / EC: Fix code ordering issue in ec_remove_handlers()

Revert "ACPICA: Namespace: Fix deadlock triggered by MLC support in dynamic table loading"

2016-07-11T14:18:18Z

Revert commit 2f38b1b16d92 (ACPICA: Namespace: Fix deadlock triggered by MLC support in dynamic table loading) that attempted to fix a deadlock issue introduced by a previous commit, but it led to a lock ordering inconsistency that caused further problems to appear. Fixes: 2f38b1b16d92 (ACPICA: Namespace: Fix deadlock triggered by MLC support in dynamic table loading) Signed-off-by: Rafael J. Wysocki

Revert "ACPICA: Namespace: Fix namespace/interpreter lock ordering"

2016-07-11T14:17:37Z

Revert commit 45209046c47b (ACPICA: Namespace: Fix namespace/interpreter lock ordering) that renders Dell Precision 5510 with the latest (1.2.10) BIOS applied unable to boot. Fixes: 45209046c47b (ACPICA: Namespace: Fix namespace/interpreter lock ordering) Link: https://bugzilla.kernel.org/show_bug.cgi?id=121701 Reported-by: Greg White Signed-off-by: Rafael J. Wysocki

ACPI / EC: Fix code ordering issue in ec_remove_handlers()

2016-07-08T19:44:12Z

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 Reported-by: Nicholas Signed-off-by: Lv Zheng [ rjw: Changelog ] Signed-off-by: Rafael J. Wysocki

Merge branches 'acpica-fixes', 'acpi-pci-fixes' and 'acpi-debug-fixes'

2016-07-07T21:37:37Z

* 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

ACPI / debugger: Fix regression introduced by IS_ERR_VALUE() removal

2016-07-05T21:02:34Z

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 [ rjw: Simplifications, changelog & subject massage ] Signed-off-by: Rafael J. Wysocki

ACPICA: Namespace: Fix namespace/interpreter lock ordering

2016-07-05T20:48:44Z

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 Signed-off-by: Rafael J. Wysocki

ACPI,PCI,IRQ: separate ISA penalty calculation

2016-07-01T23:38:34Z

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 Tested-by: Wim Osterholt Signed-off-by: Rafael J. Wysocki