Re: Patch "ACPI / EC: Add support to disallow QR_EC to be issued when SCI_EVT isn't set" has been added to the 3.16-stable tree

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



I think this patch together with
"acpi-ec-add-support-to-disallow-qr_ec-to-be-issued-before-completing-previous-qr_ec.patch"
should be added to 3.14 too.

The problem is present in 3.14 since 3.14.13. And, if I remember
correctly, these patches apply cleanly to 3.14.18.

2014-09-13 8:32 GMT+07:00  <gregkh@xxxxxxxxxxxxxxxxxxx>:
>
> This is a note to let you know that I've just added the patch titled
>
>     ACPI / EC: Add support to disallow QR_EC to be issued when SCI_EVT isn't set
>
> to the 3.16-stable tree which can be found at:
>     http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
>
> The filename of the patch is:
>      acpi-ec-add-support-to-disallow-qr_ec-to-be-issued-when-sci_evt-isn-t-set.patch
> and it can be found in the queue-3.16 subdirectory.
>
> If you, or anyone else, feels it should not be added to the stable tree,
> please let <stable@xxxxxxxxxxxxxxx> know about it.
>
>
> From 3afcf2ece453e1a8c2c6de19cdf06da3772a1b08 Mon Sep 17 00:00:00 2001
> From: Lv Zheng <lv.zheng@xxxxxxxxx>
> Date: Thu, 21 Aug 2014 14:41:13 +0800
> Subject: ACPI / EC: Add support to disallow QR_EC to be issued when SCI_EVT isn't set
>
> From: Lv Zheng <lv.zheng@xxxxxxxxx>
>
> commit 3afcf2ece453e1a8c2c6de19cdf06da3772a1b08 upstream.
>
> 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@xxxxxxxxx>
> Signed-off-by: Lv Zheng <lv.zheng@xxxxxxxxx>
> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@xxxxxxxxx>
> Signed-off-by: Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx>
>
> ---
>  drivers/acpi/ec.c |   17 ++++++++++++++++-
>  1 file changed, 16 insertions(+), 1 deletion(-)
>
> --- a/drivers/acpi/ec.c
> +++ b/drivers/acpi/ec.c
> @@ -197,6 +197,8 @@ static bool advance_transaction(struct a
>                                 t->rdata[t->ri++] = acpi_ec_read_data(ec);
>                                 if (t->rlen == t->ri) {
>                                         t->flags |= ACPI_EC_COMMAND_COMPLETE;
> +                                       if (t->command == ACPI_EC_COMMAND_QUERY)
> +                                               pr_debug("hardware QR_EC completion\n");
>                                         wakeup = true;
>                                 }
>                         } else
> @@ -208,7 +210,20 @@ static bool advance_transaction(struct a
>                 }
>                 return wakeup;
>         } else {
> -               if ((status & ACPI_EC_FLAG_IBF) == 0) {
> +               /*
> +                * There is firmware refusing 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
> +                */
> +               if (!(status & ACPI_EC_FLAG_SCI) &&
> +                   (t->command == ACPI_EC_COMMAND_QUERY)) {
> +                       t->flags |= ACPI_EC_COMMAND_POLL;
> +                       t->rdata[t->ri++] = 0x00;
> +                       t->flags |= ACPI_EC_COMMAND_COMPLETE;
> +                       pr_debug("software QR_EC completion\n");
> +                       wakeup = true;
> +               } else if ((status & ACPI_EC_FLAG_IBF) == 0) {
>                         acpi_ec_write_cmd(ec, t->command);
>                         t->flags |= ACPI_EC_COMMAND_POLL;
>                 } else
>
>
> Patches currently in stable-queue which might be from lv.zheng@xxxxxxxxx are
>
> queue-3.16/acpica-utilities-fix-memory-leak-in-acpi_ut_copy_iobject_to_iobject.patch
> queue-3.16/acpica-namespace-properly-null-terminate-objects-detached-from-a-namespace-node.patch
> queue-3.16/acpi-ec-add-support-to-disallow-qr_ec-to-be-issued-when-sci_evt-isn-t-set.patch
> queue-3.16/acpi-ec-add-support-to-disallow-qr_ec-to-be-issued-before-completing-previous-qr_ec.patch
--
To unsubscribe from this list: send the line "unsubscribe stable" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Linux Kernel]     [Kernel Development Newbies]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite Hiking]     [Linux Kernel]     [Linux SCSI]