Hi, Greg and Alexander > From: Alexander Mezin [mailto:mezin.alexander@xxxxxxxxx] > Sent: Sunday, September 14, 2014 11:32 PM > > 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. According to my mail queue. It seems the original EC race fix that triggered the hidden bug has been back ported to the following kernels: 3.14-stable/3.15-stable. And the following kernels by other maintainers. 3.13.11.6 -stable by Kamal Mostafa 3.2.62-rc1 by Ben Hutchings 3.11.10.14 -stable by Luis Henriques 3.12 stable by Jiri Slaby So let me have them informed. Thanks and best regards -Lv > 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 ��.n��������+%������w��{.n�����������ܨ}���Ơz�j:+v�����w����ޙ��&�)ߡ�a����z�ޗ���ݢj��w�f