From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754639AbdJINSF (ORCPT ); Mon, 9 Oct 2017 09:18:05 -0400 Received: from shadbolt.e.decadent.org.uk ([88.96.1.126]:41950 "EHLO shadbolt.e.decadent.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754258AbdJIMo6 (ORCPT ); Mon, 9 Oct 2017 08:44:58 -0400 Content-Type: text/plain; charset="UTF-8" Content-Disposition: inline Content-Transfer-Encoding: 8bit MIME-Version: 1.0 From: Ben Hutchings To: linux-kernel@vger.kernel.org, stable@vger.kernel.org CC: akpm@linux-foundation.org, "Lv Zheng" , "Rafael J. Wysocki" Date: Mon, 09 Oct 2017 13:44:25 +0100 Message-ID: X-Mailer: LinuxStableQueue (scripts by bwh) Subject: [PATCH 3.16 155/192] Revert "ACPI / EC: Add support to disallow QR_EC to be issued before completing previous QR_EC" In-Reply-To: X-SA-Exim-Connect-IP: 2a02:8011:400e:2:6f00:88c8:c921:d332 X-SA-Exim-Mail-From: ben@decadent.org.uk X-SA-Exim-Scanned: No (on shadbolt.decadent.org.uk); SAEximRunCond expanded to false Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 3.16.49-rc1 review patch. If anyone has any objections, please let me know. ------------------ From: Lv Zheng commit df9ff91801da603079018f21a9412385b62f0f8e upstream. It is reported that the following commit breaks Samsung hardware: Commit: 558e4736f2e1b0e6323adf7a5e4df77ed6cfc1a4. Subject: ACPI / EC: Add support to disallow QR_EC to be issued before completing previous QR_EC Which means the Samsung behavior conflicts with the Acer behavior. 1. Samsung may behave like: [ +event 1 ] SCI_EVT set [ +event 2 ] SCI_EVT set write QR_EC read event [ -event 1 ] SCI_EVT clear Without the above commit, Samsung can work: [ +event 1 ] SCI_EVT set [ +event 2 ] SCI_EVT set write QR_EC CAN prepare next QR_EC as SCI_EVT=1 read event [ -event 1 ] SCI_EVT clear write QR_EC read event [ -event 2 ] SCI_EVT clear With the above commit, Samsung cannot work: [ +event 1 ] SCI_EVT set [ +event 2 ] SCI_EVT set write QR_EC read event [ -event 1 ] SCI_EVT clear CANNOT prepare next QR_EC as SCI_EVT=0 2. Acer may behave like: [ +event 1 ] SCI_EVT set [ +event 2 ] write QR_EC read event [ -event 1 ] SCI_EVT clear [ +event 2 ] SCI_EVT set Without the above commit, Acer cannot work when there is only 1 event: [ +event 1 ] SCI_EVT set write QR_EC can prepared next QR_EC as SCI_EVT=1 read event [ -event 1 ] SCI_EVT clear CANNOT write QR_EC as SCI_EVT=0 With the above commit, Acer can work: [ +event 1 ] SCI_EVT set [ +event 2 ] write QR_EC read event [ -event 1 ] SCI_EVT set can prepare next QR_EC because SCI_EVT=0 CAN write QR_EC as SCI_EVT=1 Since Acer can also work with only the following commit applied: Commit: 3afcf2ece453e1a8c2c6de19cdf06da3772a1b08 Subject: ACPI / EC: Add support to disallow QR_EC to be issued when SCI_EVT isn't set commit 558e4736f2e1b0e6323adf7a5e4df77ed6cfc1a4 can be reverted. Fixes: 558e4736f2e1 (ACPI / EC: Add support to disallow QR_EC to be issued ...) Link: https://bugzilla.kernel.org/show_bug.cgi?id=44161 Reported-and-tested-by: Ortwin Glück Signed-off-by: Lv Zheng Signed-off-by: Rafael J. Wysocki [bwh: Backported to 3.16: adjust context] Signed-off-by: Ben Hutchings --- drivers/acpi/ec.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) --- a/drivers/acpi/ec.c +++ b/drivers/acpi/ec.c @@ -299,11 +299,11 @@ static int acpi_ec_transaction_unlocked( /* following two actions should be kept atomic */ ec->curr = t; start_transaction(ec); + if (ec->curr->command == ACPI_EC_COMMAND_QUERY) + clear_bit(EC_FLAGS_QUERY_PENDING, &ec->flags); spin_unlock_irqrestore(&ec->lock, tmp); ret = ec_poll(ec); spin_lock_irqsave(&ec->lock, tmp); - if (ec->curr->command == ACPI_EC_COMMAND_QUERY) - clear_bit(EC_FLAGS_QUERY_PENDING, &ec->flags); ec->curr = NULL; spin_unlock_irqrestore(&ec->lock, tmp); return ret;