Received: by 2002:a25:4158:0:0:0:0:0 with SMTP id o85csp881016yba; Thu, 18 Apr 2019 11:07:32 -0700 (PDT) X-Google-Smtp-Source: APXvYqzjZpTbjX6FHrSO2ah5drMRQaZ43N+9kZOFHugszkgAh0upWtCLLokq47MmsjZqb4+ETEju X-Received: by 2002:a17:902:988e:: with SMTP id s14mr93683033plp.167.1555610852066; Thu, 18 Apr 2019 11:07:32 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1555610852; cv=none; d=google.com; s=arc-20160816; b=xvzdHZGJOuV8Qf5fVAk2jozL9XyudtPB+LzFTGv3CJzTUMQUiUCOIXaobpnm3To//+ IwR5diVQt6fNrG4IdrRGGHz5sCxPVAxFYYxtE6yZp5Qi/glQPVV5nHKs2bGULoVmmFJ0 fUbD2ybNFUlntWHL8ZzQwHPjITWOHzsB3SaTvqPE43SXajGN6zhFtnhJtPGOsjq83vJa 4hix+AJU2HywPA3i2z8kYeghRybznshfaDYuS97JHp/6gRfwEHE6FulKvystYCQX/xyj MVU9lCsGVHmwCNPcKScu+lXyYhCDiy26veD6I8oWfyBrxijDxGcD8/c/tYbamfKcge2L tKnA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :user-agent:references:in-reply-to:message-id:date:subject:cc:to :from:dkim-signature; bh=PPGEPgHyPNFz378qV8xaez90MT8hBcz91QDMQ5TNkCw=; b=BWDhQ4+uQ6XQ3QRKOhhoBAqvpLmmrM0u9SuU116PRLTt77vX5BAQuVxbE4NcAEPUgg 1vK9mbxp1JJL4iz59VUthYFOCkmghTZSd1o9nIha7uIL4fkLypfF2Ip3SUJCUXJtARwf bAHKnHZEe5rnUyxtxPP834iRHvoWUmOGVj9w0M329IXB4fsDH43zWc0PS2wOAW0cZCTF XyKAotUCaLVDToEzU2y1FiTVgGgqs7spDhyFX+lQYOojAQ+gPxeHJtwJOzItIXlIM5n9 DqKZPqUBzUJ90BudBwkZ9TlxleFsInFGDp55IhSNgXGFUrEJsbzXwAeNIDv8Ftf2XT+u +Swg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=uooGbSrm; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id 15si3115036pfz.73.2019.04.18.11.07.17; Thu, 18 Apr 2019 11:07:32 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=uooGbSrm; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2391343AbfDRSFg (ORCPT + 99 others); Thu, 18 Apr 2019 14:05:36 -0400 Received: from mail.kernel.org ([198.145.29.99]:34952 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2390694AbfDRSFd (ORCPT ); Thu, 18 Apr 2019 14:05:33 -0400 Received: from localhost (83-86-89-107.cable.dynamic.v4.ziggo.nl [83.86.89.107]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id CF54A206B6; Thu, 18 Apr 2019 18:05:32 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1555610733; bh=xNq303BhfemEsOdPOn1FUmuCKF2Nq0lhdoWpvdsw77U=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=uooGbSrm6asDaDpDZLAH/nrI4amE7LaNrkR36pUqqbOxPz45Jg7mVqBCa3pNOZaGA K/7nKlS3dpsE/RkG8U3Fg25xJXa3v9Qy0BciPsZyPLOAUSbLq2M4qVJ1Uc9XRAe3U4 YOatkV+M8wQaj+tJtCviYCNq+57KpVM/t+ptuEug= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, =?UTF-8?q?Ortwin=20Gl=C3=BCck?= , Francisco Cribari , Balazs Varga , Zhang Rui , "Rafael J. Wysocki" , Sasha Levin Subject: [PATCH 4.14 63/92] Revert "ACPI / EC: Remove old CLEAR_ON_RESUME quirk" Date: Thu, 18 Apr 2019 19:57:21 +0200 Message-Id: <20190418160435.722121589@linuxfoundation.org> X-Mailer: git-send-email 2.21.0 In-Reply-To: <20190418160430.325165109@linuxfoundation.org> References: <20190418160430.325165109@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org [ Upstream commit b6a3e1475b0220378ad32bdf4d8692f058b1fc03 ] On some Samsung hardware, it is necessary to clear events accumulated by the EC during sleep. These ECs stop reporting GPEs until they are manually polled, if too many events are accumulated. Thus the CLEAR_ON_RESUME quirk is introduced to send EC query commands unconditionally after resume to clear all the EC query events on those platforms. Later, commit 4c237371f290 ("ACPI / EC: Remove old CLEAR_ON_RESUME quirk") removes the CLEAR_ON_RESUME quirk because we thought the new EC IRQ polling logic should handle this case. Now it has been proved that the EC IRQ Polling logic does not fix the issue actually because we got regression report on these Samsung platforms after removing the quirk. Thus revert commit 4c237371f290 ("ACPI / EC: Remove old CLEAR_ON_RESUME quirk") to introduce back the Samsung quirk in this patch. Link: https://bugzilla.kernel.org/show_bug.cgi?id=44161 Tested-by: Ortwin Glück Tested-by: Francisco Cribari Tested-by: Balazs Varga Signed-off-by: Zhang Rui Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin --- drivers/acpi/ec.c | 53 +++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 53 insertions(+) diff --git a/drivers/acpi/ec.c b/drivers/acpi/ec.c index 3d624c72c6c2..ebfc06f29f7b 100644 --- a/drivers/acpi/ec.c +++ b/drivers/acpi/ec.c @@ -194,6 +194,7 @@ static struct workqueue_struct *ec_query_wq; static int EC_FLAGS_QUERY_HANDSHAKE; /* Needs QR_EC issued when SCI_EVT set */ static int EC_FLAGS_CORRECT_ECDT; /* Needs ECDT port address correction */ static int EC_FLAGS_IGNORE_DSDT_GPE; /* Needs ECDT GPE as correction setting */ +static int EC_FLAGS_CLEAR_ON_RESUME; /* Needs acpi_ec_clear() on boot/resume */ /* -------------------------------------------------------------------------- * Logging/Debugging @@ -499,6 +500,26 @@ static inline void __acpi_ec_disable_event(struct acpi_ec *ec) ec_log_drv("event blocked"); } +/* + * Process _Q events that might have accumulated in the EC. + * Run with locked ec mutex. + */ +static void acpi_ec_clear(struct acpi_ec *ec) +{ + int i, status; + u8 value = 0; + + for (i = 0; i < ACPI_EC_CLEAR_MAX; i++) { + status = acpi_ec_query(ec, &value); + if (status || !value) + break; + } + if (unlikely(i == ACPI_EC_CLEAR_MAX)) + pr_warn("Warning: Maximum of %d stale EC events cleared\n", i); + else + pr_info("%d stale EC events cleared\n", i); +} + static void acpi_ec_enable_event(struct acpi_ec *ec) { unsigned long flags; @@ -507,6 +528,10 @@ static void acpi_ec_enable_event(struct acpi_ec *ec) if (acpi_ec_started(ec)) __acpi_ec_enable_event(ec); spin_unlock_irqrestore(&ec->lock, flags); + + /* Drain additional events if hardware requires that */ + if (EC_FLAGS_CLEAR_ON_RESUME) + acpi_ec_clear(ec); } #ifdef CONFIG_PM_SLEEP @@ -1802,6 +1827,31 @@ static int ec_flag_query_handshake(const struct dmi_system_id *id) } #endif +/* + * On some hardware it is necessary to clear events accumulated by the EC during + * sleep. These ECs stop reporting GPEs until they are manually polled, if too + * many events are accumulated. (e.g. Samsung Series 5/9 notebooks) + * + * https://bugzilla.kernel.org/show_bug.cgi?id=44161 + * + * Ideally, the EC should also be instructed NOT to accumulate events during + * sleep (which Windows seems to do somehow), but the interface to control this + * behaviour is not known at this time. + * + * Models known to be affected are Samsung 530Uxx/535Uxx/540Uxx/550Pxx/900Xxx, + * however it is very likely that other Samsung models are affected. + * + * On systems which don't accumulate _Q events during sleep, this extra check + * should be harmless. + */ +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; +} + /* * Some ECDTs contain wrong register addresses. * MSI MS-171F @@ -1851,6 +1901,9 @@ static const struct dmi_system_id ec_dmi_table[] __initconst = { ec_honor_ecdt_gpe, "ASUS X580VD", { DMI_MATCH(DMI_SYS_VENDOR, "ASUSTeK COMPUTER INC."), DMI_MATCH(DMI_PRODUCT_NAME, "X580VD"),}, NULL}, + { + ec_clear_on_resume, "Samsung hardware", { + DMI_MATCH(DMI_SYS_VENDOR, "SAMSUNG ELECTRONICS CO., LTD.")}, NULL}, {}, }; -- 2.19.1