kernel/linux.git/drivers/acpi/ec.c, branch v4.4.171

ACPI / EC: Work around method reentrancy limit in ACPICA for _Qxx

2016-08-20T16:09:27+00:00

commit e1191bd4f62d9086a1a47adc286e7fcffc1fa55c upstream. A regression is caused by the following commit: Commit: 02b771b64b73226052d6e731a0987db3b47281e9 Subject: ACPI / EC: Fix an issue caused by the serialized _Qxx evaluations In this commit, using system workqueue causes that the maximum parallel executions of _Qxx can exceed 255. This violates the method reentrancy limit in ACPICA and generates the following error log: ACPI Error: Method reached maximum reentrancy limit (255) (20150818/dsmethod-341) This patch creates a seperate workqueue and limits the number of parallel _Qxx evaluations down to a configurable value (can be tuned against number of online CPUs). Since EC events are handled after driver probe, we can create the workqueue in acpi_ec_init(). Fixes: 02b771b64b73 (ACPI / EC: Fix an issue caused by the serialized _Qxx evaluations) Link: https://bugzilla.kernel.org/show_bug.cgi?id=135691 Reported-and-tested-by: Helen Buus Signed-off-by: Lv Zheng Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman

ACPI-EC: Drop unnecessary check made before calling acpi_ec_delete_query()

2015-11-16T22:29:44+00:00

The acpi_ec_delete_query() function tests whether its argument is NULL and then returns immediately. Thus the test around the call is not needed. This issue was detected by using the Coccinelle software. Signed-off-by: Markus Elfring [ rjw: Subject ] Signed-off-by: Rafael J. Wysocki

ACPI / EC: Fix a race issue in acpi_ec_guard_event()

2015-09-25T23:46:25+00:00

In acpi_ec_guard_event(), EC transaction state machine variables should be checked with the EC spinlock locked. The bug doesn't trigger any real issue now because this bug can only occur when the ec_event_clearing=event mode is applied while there is no user currently using this mode. Signed-off-by: Lv Zheng Signed-off-by: Rafael J. Wysocki

ACPI / EC: Fix query handler related issues

2015-09-25T23:46:24+00:00

1. acpi_ec_remove_query_handlers() This patch refines the query handler removal logic implemented in acpi_ec_remove_query_handler(), making it to invoke new acpi_ec_remove_query_handlers() API, and ensuring all other removal code paths to invoke the new API to honor the reference count of the query handlers. 2. acpi_ec_get_query_handler_by_value() This patch also refines the query handler search logic originally implemented in acpi_ec_query(), collecting it into acpi_ec_get_query_handler_by_value(). And since schedule_work() can ensure the serilization of acpi_ec_event_handler(), we needn't put the mutex_lock() around schedule_work(). Signed-off-by: Lv Zheng Signed-off-by: Rafael J. Wysocki

ACPI / EC: Fix a memory leak issue in acpi_ec_query()

2015-09-25T23:44:59+00:00

When query handler is not found, "result" is actually stil 0, and "struct acpi_ec_query" is not NULL, so the deletion code of "struct acpi_ec_query" at the end of the function cannot be invoked. As a consequence, memory leak can be observed. The issue is introduced by this commit: Commit: 02b771b64b73226052d6e731a0987db3b47281e9 Subject: ACPI / EC: Fix an issue caused by the serialized _Qxx This patch fixes such memory leakage. Fixes: 02b771b64b73 (ACPI / EC: Fix an issue caused by the serialized _Qxx evaluations) Signed-off-by: Lv Zheng Signed-off-by: Rafael J. Wysocki

Merge branches 'acpi-pci', 'acpi-soc', 'acpi-ec' and 'acpi-osl'

2015-09-01T01:41:19+00:00

* acpi-pci: ACPI, PCI: Penalize legacy IRQ used by ACPI SCI * acpi-soc: ACPI / LPSS: Ignore 10ms delay for Braswell * acpi-ec: ACPI / EC: Fix an issue caused by the serialized _Qxx evaluations * acpi-osl: ACPI / osl: replace custom implementation of readq / writeq

ACPI / EC: Fix an issue caused by the serialized _Qxx evaluations

2015-08-25T01:19:32+00:00

It is proven that Windows evaluates _Qxx handlers in a parallel way. This patch follows this fact, splits _Qxx evaluations from the NOTIFY queue to form a separate queue, so that _Qxx evaluations can be queued up on different CPUs rather than being queued up on a CPU0 bound queue. Event handling related callbacks are also renamed and sorted in this patch. Link: https://bugzilla.kernel.org/show_bug.cgi?id=94411 Reported-and-tested-by: Gabriele Mazzotta Signed-off-by: Lv Zheng Signed-off-by: Rafael J. Wysocki

ACPI: Remove FSF mailing addresses

2015-07-08T00:27:32+00:00

There is no need to carry potentially outdated Free Software Foundation mailing address in file headers since the COPYING file includes it. Signed-off-by: Jarkko Nikula Signed-off-by: Rafael J. Wysocki

ACPI / EC: Fix a code coverity issue when QR_EC transactions are failed.

2015-06-15T12:35:59+00:00

When the QR_EC transaction fails, the EC_FLAGS_QUERY_PENDING flag prevents the event handling work queue from being scheduled again. Though there shouldn't be failed QR_EC transactions, and this gap was efficiently used for catching and learning the SCI_EVT clearing timing compliance issues, we need to fix this as we are not fully compatible with all platforms/Windows to handle SCI_EVT clearing timing correctly. Fixing this gives the EC driver the chances to recover from a state machine failure. So this patch fixes this issue. When nr_pending_queries drops to 0, it clears EC_FLAGS_QUERY_PENDING at the proper position for different modes in order to ensure that the SCI_EVT handling can proceed. In order to be clearer for future ec_event_clearing modes, all checks in this patch are written in the inclusive style, not the exclusive style. Cc: 3.16+ # 3.16+ Signed-off-by: Lv Zheng Signed-off-by: Rafael J. Wysocki

ACPI / EC: Fix EC_FLAGS_QUERY_HANDSHAKE platforms using new event clearing timing.

2015-06-15T12:35:59+00:00

It is reported that on several platforms, EC firmware will not respond non-expected QR_EC (see EC_FLAGS_QUERY_HANDSHAKE, only write QR_EC when SCI_EVT is set). Unfortunately, ACPI specification doesn't define when the SCI_EVT should be cleared by the firmware, thus the original implementation queued up second QR_EC right after writing QR_EC command and before reading the returned event value as at that time the SCI_EVT is ensured not cleared. This behavior is also based on the assumption that the firmware should be able to return 0x00 to indicate "no outstanding event". This behavior did fix issues on Samsung platforms where the spurious query value of 0x00 is supported and didn't break platforms in my test queue. But recently, specific Acer, Asus, Lenovo platforms keep on blaming this change. This patch changes the behavior to re-check the SCI_EVT a bit later and removes EC_FLAGS_QUERY_HANDSHAKE quirks, hoping this is the Windows compliant EC driver behavior. In order to be robust to the possible regressions, instead of removing the quirk directly, this patch keeps the quirk code, removes the quirk users and keeps old behavior for Samsung platforms. Cc: 3.16+ # 3.16+ 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 Reported-and-tested-by: Tigran Gabrielyan Reported-and-tested-by: Adrien D Signed-off-by: Lv Zheng Signed-off-by: Rafael J. Wysocki