ACPI / scan: Allow ACPI drivers to bind to PNP device objects

We generally don't allow ACPI drivers to bind to ACPI device objects
that companion "physical" device objects are created for to avoid
situations in which two different drivers may attempt to handle one
device at the same time.  Recent ACPI device enumeration rework
extended that approach to ACPI PNP devices by starting to use a scan
handler for enumerating them.  However, we previously allowed ACPI
drivers to bind to ACPI device objects with existing PNP device
companions and changing that led to functional regressions on some
systems.

For this reason, add a special check for PNP devices in
acpi_device_probe() so that ACPI drivers can bind to ACPI device
objects having existing PNP device companions as before.

Fixes: eec15edbb0e1 (ACPI / PNP: use device ID list for PNPACPI device enumeration)
Link: https://bugzilla.kernel.org/show_bug.cgi?id=81511
Link: https://bugzilla.kernel.org/show_bug.cgi?id=81971
Reported-by: Gabriele Mazzotta <gabriele.mzt@gmail.com>
Reported-by: Dirk Griesbach <spamthis@freenet.de>
Cc: 3.16+ <stable@vger.kernel.org> # 3.16+
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
ACPI: Run fixed event device notifications in process context

Currently, notify callbacks for fixed button events are run from
interrupt context.  That is not necessary and after commit 0bf6368ee8f2
(ACPI / button: Add ACPI Button event via netlink routine) it causes
netlink routines to be called from interrupt context which is not
correct.

Also, that is different from non-fixed device events (including
non-fixed button events) whose notify callbacks are all executed from
process context.

For the above reasons, make fixed button device notify callbacks run
in process context which will avoid the deadlock when using netlink
to report button events to user space.

Fixes: 0bf6368ee8f2 (ACPI / button: Add ACPI Button event via netlink routine)
Link: https://lkml.org/lkml/2014/8/21/606
Reported-by: Benjamin Block <bebl@mageta.org>
Reported-by: Knut Petersen <Knut_Petersen@t-online.de>
Signed-off-by: Lan Tianyu <tianyu.lan@intel.com>
[rjw: Function names, subject and changelog.]
Cc: 3.15+ <stable@vger.kernel.org> # 3.15+
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
ACPI / OSL: Make acpi_os_map_cleanup() use call_rcu() to avoid deadlocks

Deadlock is possible when CPU hotplug and evaluating ACPI method happen
at the same time.

During CPU hotplug, acpi_cpu_soft_notify() is called under the CPU hotplug
lock.  Then, acpi_cpu_soft_notify() calls acpi_bus_get_device() to obtain
the struct acpi_device attached to the given ACPI handle.  The ACPICA's
namespace lock will be acquired by acpi_bus_get_device() in the process.
Thus it is possible to hold the ACPICA's namespace lock under the CPU
hotplug lock.

Evaluating an ACPI method may involve accessing an operation region in
system memory and the associated address space will be unmapped under
the ACPICA's namespace lock after completing the access. Currently, osl.c
uses RCU to protect memory ranges used by AML.  When unmapping them it
calls synchronize_rcu() in acpi_os_map_cleanup(), but that blocks
CPU hotplug by acquiring the CPU hotplug lock.  Thus it is possible to
hold the CPU hotplug lock under the ACPICA's namespace lock.

This leads to deadlocks like the following one if AML accessing operation
regions in memory is executed in parallel with CPU hotplug.

INFO: task bash:741 blocked for more than 30 seconds.
      Not tainted 3.16.0-rc5+ #671
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
bash            D ffff88014e214140     0   741    716 0x00000080
 ffff88009b9f3a10 0000000000000086 ffff88009dcfb840 ffff88009b9f3fd8
 0000000000014140 0000000000014140 ffffffff81c18460 ffffffff81c40fc8
 ffffffff81c40fcc ffff88009dcfb840 00000000ffffffff ffffffff81c40fd0
Call Trace:
 [<ffffffff817a1b29>] schedule_preempt_disabled+0x29/0x70
 [<ffffffff817a34fa>] __mutex_lock_slowpath+0xca/0x1c0
 [<ffffffff817a360f>] mutex_lock+0x1f/0x2f
 [<ffffffff810bc8cc>] get_online_cpus+0x2c/0x50
 [<ffffffff8111bbd4>] synchronize_sched_expedited+0x64/0x1c0
 [<ffffffff8111bb65>] synchronize_sched+0x45/0x50
 [<ffffffff81431498>] acpi_os_map_cleanup.part.7+0x14/0x3e
 [<ffffffff81795c54>] acpi_os_unmap_iomem+0xe2/0xea
 [<ffffffff81795c6a>] acpi_os_unmap_memory+0xe/0x14
 [<ffffffff814459bc>] acpi_ev_system_memory_region_setup+0x2d/0x97
 [<ffffffff81459504>] acpi_ut_update_ref_count+0x24d/0x2de
 [<ffffffff814596af>] acpi_ut_update_object_reference+0x11a/0x18b
 [<ffffffff81459282>] acpi_ut_remove_reference+0x2e/0x31
 [<ffffffff8144ffdf>] acpi_ns_detach_object+0x7b/0x80
 [<ffffffff8144ef11>] acpi_ns_delete_namespace_subtree+0x47/0x81
 [<ffffffff81440488>] acpi_ds_terminate_control_method+0x85/0x11b
 [<ffffffff81454625>] acpi_ps_parse_aml+0x164/0x289
 [<ffffffff81454da6>] acpi_ps_execute_method+0x1c1/0x26c
 [<ffffffff8144f764>] acpi_ns_evaluate+0x1c1/0x258
 [<ffffffff81451f86>] acpi_evaluate_object+0x126/0x22f
 [<ffffffff8144d1ac>] acpi_hw_execute_sleep_method+0x3d/0x68
 [<ffffffff8144d5cf>] ? acpi_hw_enable_all_runtime_gpes+0x17/0x19
 [<ffffffff8144deb0>] acpi_hw_legacy_wake+0x4d/0x9d
 [<ffffffff8144e599>] acpi_hw_sleep_dispatch+0x2a/0x2c
 [<ffffffff8144e5cb>] acpi_leave_sleep_state+0x17/0x19
 [<ffffffff8143335c>] acpi_pm_finish+0x3f/0x99
 [<ffffffff81108c49>] suspend_devices_and_enter+0x139/0x560
 [<ffffffff81109162>] pm_suspend+0xf2/0x370
 [<ffffffff81107e69>] state_store+0x79/0xf0
 [<ffffffff813bc4af>] kobj_attr_store+0xf/0x20
 [<ffffffff81284f3d>] sysfs_kf_write+0x3d/0x50
 [<ffffffff81284580>] kernfs_fop_write+0xe0/0x160
 [<ffffffff81210f47>] vfs_write+0xb7/0x1f0
 [<ffffffff81211ae6>] SyS_write+0x46/0xb0
 [<ffffffff8114d986>] ? __audit_syscall_exit+0x1f6/0x2a0
 [<ffffffff817a4ea9>] system_call_fastpath+0x16/0x1b
INFO: task async-enable-no:749 blocked for more than 30 seconds.
      Not tainted 3.16.0-rc5+ #671
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
async-enable-no D ffff88014e254140     0   749      2 0x00000080
 ffff88009de83bf0 0000000000000046 ffff88009b850000 ffff88009de83fd8
 0000000000014140 0000000000014140 ffff880148305dc0 ffff880149804160
 7fffffffffffffff 0000000000000002 0000000000000000 ffff88009b850000
Call Trace:
 [<ffffffff817a1689>] schedule+0x29/0x70
 [<ffffffff817a0b49>] schedule_timeout+0x1f9/0x270
 [<ffffffff81284bfe>] ? __kernfs_create_file+0x7e/0xa0
 [<ffffffff8128546b>] ? sysfs_add_file_mode_ns+0x9b/0x160
 [<ffffffff817a36b2>] __down_common+0x93/0xd8
 [<ffffffff817a376a>] __down_timeout+0x16/0x18
 [<ffffffff8110546c>] down_timeout+0x4c/0x60
 [<ffffffff81431f97>] acpi_os_wait_semaphore+0x43/0x57
 [<ffffffff8145a8f4>] acpi_ut_acquire_mutex+0x48/0x88
 [<ffffffff81435d1b>] ? acpi_match_device+0x4f/0x4f
 [<ffffffff8145250f>] acpi_get_data_full+0x3a/0x8e
 [<ffffffff81435b30>] acpi_bus_get_device+0x23/0x40
 [<ffffffff8145d839>] acpi_cpu_soft_notify+0x50/0xe6
 [<ffffffff810e1ddc>] notifier_call_chain+0x4c/0x70
 [<ffffffff810e1eee>] __raw_notifier_call_chain+0xe/0x10
 [<ffffffff810bc993>] cpu_notify+0x23/0x50
 [<ffffffff810bcb98>] _cpu_up+0x168/0x180
 [<ffffffff810bcc5c>] _cpu_up_with_trace+0x2c/0xe0
 [<ffffffff810bd050>] ? disable_nonboot_cpus+0x1c0/0x1c0
 [<ffffffff810bd06f>] async_enable_nonboot_cpus+0x1f/0x70
 [<ffffffff810dda02>] kthread+0xd2/0xf0
 [<ffffffff810dd930>] ? insert_kthread_work+0x40/0x40
 [<ffffffff817a4dfc>] ret_from_fork+0x7c/0xb0

To avoid such deadlocks, modify acpi_os_map_cleanup() to use call_rcu()
for the unmapping of memory regions that aren't used any more.

Signed-off-by: Lan Tianyu <tianyu.lan@intel.com>
[rjw: Subject and changelog.]
Cc: All applicable <stable@vger.kernel.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
ACPI / EC: Add support to disallow QR_EC to be issued when SCI_EVT isn't set

There is a platform refusing to respond QR_EC when SCI_EVT isn't set
(Acer Aspire V5-573G).

Currently, we rely on the behaviour that the EC firmware can respond
something (for example, 0x00 to indicate "no outstanding events") to
QR_EC even when SCI_EVT is not set, but the reporter has complained
about AC/battery pluging/unpluging and video brightness change delay
on that platform.

This is because the work item that has issued QR_EC has to wait until
timeout in this case, and the _Qxx method evaluation work item queued
after QR_EC one is delayed.

It sounds reasonable to fix this issue by:
 1. Implementing SCI_EVT sanity check before issuing QR_EC in the EC
    driver's main state machine.
 2. Moving QR_EC issuing out of the work queue used by _Qxx evaluation
    to a seperate IRQ handling thread.

This patch fixes this issue using solution 1.

By disallowing QR_EC to be issued when SCI_EVT isn't set, we are able to
handle such platform in the EC driver's main state machine. This patch
enhances the state machine in this way to survive with such malfunctioning
EC firmware.

Note that this patch can also fix CLEAR_ON_RESUME quirk which also relies
on the assumption that the platforms are able to respond even when SCI_EVT
isn't set.

Fixes: c0d653412fc8 ACPI / EC: Fix race condition in ec_transaction_completed()
Link: https://bugzilla.kernel.org/show_bug.cgi?id=82611
Reported-and-tested-by: Alexander Mezin <mezin.alexander@gmail.com>
Signed-off-by: Lv Zheng <lv.zheng@intel.com>
Cc: 3.16+ <stable@vger.kernel.org> # 3.16+
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
ACPI / EC: Add support to disallow QR_EC to be issued before completing previous QR_EC

There is platform refusing to respond QR_EC when SCI_EVT isn't set
which is Acer Aspire V5-573G.

By disallowing QR_EC to be issued before the previous one has been
completed we are able to reduce the possibilities to trigger issues on
such platforms.

Note that this fix can only reduce the occurrence rate of this issue, but
this issue may still occur when such a platform doesn't clear SCI_EVT
before or immediately after completing the previous QR_EC transaction.
This patch cannot fix the CLEAR_ON_RESUME quirk which also relies on
the assumption that the platforms are able to respond even when SCI_EVT
isn't set.

But this patch is still useful as it can help to reduce the number of
scheduled QR_EC work items.

Link: https://bugzilla.kernel.org/show_bug.cgi?id=82611
Reported-and-tested-by: Alexander Mezin <mezin.alexander@gmail.com>
Signed-off-by: Lv Zheng <lv.zheng@intel.com>
Cc: 3.16+ <stable@vger.kernel.org> # 3.16+
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
ACPI / LPSS: Add ACPI IDs for Intel Braswell

Enable more identifiers for the existing devices for Intel Braswell and
Cherryview.

Signed-off-by: Alan Cox <alan@linux.intel.com>
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Revert "ACPI / video: Change the default for video.use_native_backlight to 1"

Revert commit 751109aad5834 (ACPI / video: Change the default for
video.use_native_backlight to 1) as problems with it are being reported
by more and more people and we have a list of systems that require the
value of use_native_backlight to be 1 anyway.

Fixes: 751109aad5834 (ACPI / video: Change the default for video.use_native_backlight to 1)
Link: https://bugzilla.kernel.org/show_bug.cgi?id=81691
Reported-by: Andre Müller <andre.muller@web.de>
Reported-by: Uwe Bonnes <bon@elektron.ikp.physik.tu-darmstadt.de>
Cc: 3.16+ <stable@vger.kernel.org> # 3.16+
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Merge branches 'acpi-scan', 'acpi-osl', 'acpi-ec', 'acpi-lpss' and 'acpi-video'

* acpi-scan:
  ACPI: Run fixed event device notifications in process context
  ACPI / scan: Allow ACPI drivers to bind to PNP device objects

* acpi-osl:
  ACPI / OSL: Make acpi_os_map_cleanup() use call_rcu() to avoid deadlocks

* acpi-ec:
  ACPI / EC: Add support to disallow QR_EC to be issued before completing previous QR_EC
  ACPI / EC: Add support to disallow QR_EC to be issued when SCI_EVT isn't set

* acpi-lpss:
  ACPI / LPSS: Add ACPI IDs for Intel Braswell

* acpi-video:
  Revert "ACPI / video: Change the default for video.use_native_backlight to 1"