FAILED: patch "[PATCH] ACPI / EC: Fix EC_FLAGS_QUERY_HANDSHAKE platforms using new" failed to apply to 4.1-stable tree
Subsystems (2)
[email protected]
maintainerThe patch below does not apply to the 4.1-stable tree.
If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <[email protected]>.
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
Quoted 1 line
From
3cb02aeb28dd3f1b8a132fa3ecf6db17afd518d6Mon Sep 17 00:00:00 2001
From: Lv Zheng <[email protected]>
Date: Thu, 11 Jun 2015 13:21:45 +0800
Subject: [PATCH] ACPI / EC: Fix EC_FLAGS_QUERY_HANDSHAKE platforms using new
event clearing timing.
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.
drivers/acpi/ec.c +9 -7
@@ -133,7 +133,7 @@ static unsigned int ec_polling_guard __read_mostly = ACPI_EC_UDELAY_POLL;module_param (ec_polling_guard, uint,0644 );MODULE_PARM_DESC (ec_polling_guard,"Guard time(us) between EC accesses in polling modes" ); -static unsigned int ec_event_clearing__read_mostly =ACPI_EC_EVT_TIMING_STATUS ; +static unsigned int ec_event_clearing__read_mostly =ACPI_EC_EVT_TIMING_QUERY ;/* * If the number of false interrupts per one transaction exceeds
@@ -1381,10 +1381,13 @@ static int ec_validate_ecdt(const struct dmi_system_id *id)return 0 ; } +#if 0 /* -* Acer EC firmware refuses to respond QR_EC when SCI_EVT is not set, for -* which case, we complete the QR_EC without issuing it to the firmware. -* https://bugzilla.kernel.org/show_bug.cgi?id=86211 +* Some EC firmware variations refuses to respond QR_EC when SCI_EVT is not +* set, for which case, we complete the QR_EC without issuing it to the +* firmware. +* https://bugzilla.kernel.org/show_bug.cgi?id=82611 +* https://bugzilla.kernel.org/show_bug.cgi?id=97381 */ static int ec_flag_query_handshake (const struct dmi_system_id *id) {
@@ -1392,6 +1395,7 @@ static int ec_flag_query_handshake(const struct dmi_system_id *id)EC_FLAGS_QUERY_HANDSHAKE =1 ; return 0; } +#endif /* * On some hardware it is necessary to clear events accumulated by the EC during
@@ -1414,6 +1418,7 @@ static int ec_clear_on_resume(const struct dmi_system_id *id) {pr_debug ("Detected system needing EC poll on resume.\n" );EC_FLAGS_CLEAR_ON_RESUME =1 ; + ec_event_clearing =ACPI_EC_EVT_TIMING_STATUS ;return 0 ; }
@@ -1443,9 +1448,6 @@ static struct dmi_system_id ec_dmi_table[] __initdata = { { ec_clear_on_resume, "Samsung hardware", { DMI_MATCH(DMI_SYS_VENDOR, "SAMSUNG ELECTRONICS CO., LTD.")}, NULL}, - { - ec_flag_query_handshake, "Acer hardware", { - DMI_MATCH(DMI_SYS_VENDOR, "Acer"), }, NULL}, {}, };
Hi,
OK, I'll check it and send a minimal backport here.
Thanks and best regards
-Lv
Quoted 111 lines
From: [email protected] [mailto:[email protected]]
Sent: Friday, July 17, 2015 6:07 AMThe patch below does not apply to the 4.1-stable tree.
If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <[email protected]>.thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
From
3cb02aeb28dd3f1b8a132fa3ecf6db17afd518d6Mon Sep 17 00:00:00 2001
From: Lv Zheng <[email protected]>
Date: Thu, 11 Jun 2015 13:21:45 +0800
Subject: [PATCH] ACPI / EC: FixEC_FLAGS_QUERY_HANDSHAKEplatforms using new
event clearing timing.It is reported that on several platforms, EC firmware will not respond non-expected
QR_EC(seeEC_FLAGS_QUERY_HANDSHAKE, only writeQR_ECwhenSCI_EVTis set).Unfortunately, ACPI specification doesn't define when the
SCI_EVTshould be cleared by the firmware, thus the original implementation queued up secondQR_ECright after writingQR_ECcommand and before reading the returned event value as at that time theSCI_EVTis ensured not cleared. This behavior is also based on the assumption that the firmware should be able to return0x00to indicate "no outstanding event". This behavior did fix issues on Samsung platforms where the spurious query value of0x00is 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_EVTa bit later and removesEC_FLAGS_QUERY_HANDSHAKEquirks, 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+ <[email protected]> # 3.16+Reported-and-tested-by Gabriele Mazzotta <[email protected]>Reported-and-tested-by Tigran Gabrielyan <[email protected]>Reported-and-tested-by Adrien D <[email protected]>Signed-off-by Lv Zheng <[email protected]>Signed-off-by Rafael J. Wysocki <[email protected]>drivers/acpi/ec.c +9
-7@@ -133,7 +133,7 @@ static unsigned int ec_polling_guard __read_mostly = ACPI_EC_UDELAY_POLL;module_param (ec_polling_guard, uint,0644 );MODULE_PARM_DESC (ec_polling_guard,"Guard time(us) between EC accesses in polling modes" ); -static unsigned int ec_event_clearing__read_mostly =ACPI_EC_EVT_TIMING_STATUS ; +static unsigned int ec_event_clearing__read_mostly =ACPI_EC_EVT_TIMING_QUERY ;/* * If the number of false interrupts per one transaction exceeds @@ -1381,10 +1381,13 @@ static int ec_validate_ecdt(const struct dmi_system_id *id)return 0 ; } +#if 0 /* -* Acer EC firmware refuses to respond QR_EC when SCI_EVT is not set, for -* which case, we complete the QR_EC without issuing it to the firmware. -* https://bugzilla.kernel.org/show_bug.cgi?id=86211 +* Some EC firmware variations refuses to respond QR_EC when SCI_EVT is not +* set, for which case, we complete the QR_EC without issuing it to the +* firmware. +* https://bugzilla.kernel.org/show_bug.cgi?id=82611 +* https://bugzilla.kernel.org/show_bug.cgi?id=97381 */ static int ec_flag_query_handshake (const struct dmi_system_id *id) {@@ -1392,6 +1395,7 @@ static int ec_flag_query_handshake(const struct dmi_system_id *id)EC_FLAGS_QUERY_HANDSHAKE =1 ; return 0; } +#endif /* * On some hardware it is necessary to clear events accumulated by the EC during @@ -1414,6 +1418,7 @@ static int ec_clear_on_resume(const struct dmi_system_id *id) {pr_debug ("Detected system needing EC poll on resume.\n" );EC_FLAGS_CLEAR_ON_RESUME =1 ; + ec_event_clearing =ACPI_EC_EVT_TIMING_STATUS ;return 0 ; }@@ -1443,9 +1448,6 @@ static struct dmi_system_id ec_dmi_table[] __initdata = { { ec_clear_on_resume, "Samsung hardware", { DMI_MATCH(DMI_SYS_VENDOR, "SAMSUNG ELECTRONICS CO., LTD.")}, NULL}, - { - ec_flag_query_handshake, "Acer hardware", { - DMI_MATCH(DMI_SYS_VENDOR, "Acer"), }, NULL}, {}, };