From patchwork Mon Mar 24 09:30:12 2014 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Tianyu Lan X-Patchwork-Id: 3882221 Return-Path: X-Original-To: patchwork-linux-acpi@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork1.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.19.201]) by patchwork1.web.kernel.org (Postfix) with ESMTP id 3E24A9F2B6 for ; Mon, 24 Mar 2014 09:30:18 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id 4B574202E5 for ; Mon, 24 Mar 2014 09:30:17 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 4D84C201BA for ; Mon, 24 Mar 2014 09:30:16 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752249AbaCXJaO (ORCPT ); Mon, 24 Mar 2014 05:30:14 -0400 Received: from mail-qc0-f171.google.com ([209.85.216.171]:35211 "EHLO mail-qc0-f171.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752298AbaCXJaN (ORCPT ); Mon, 24 Mar 2014 05:30:13 -0400 Received: by mail-qc0-f171.google.com with SMTP id c9so5666232qcz.30 for ; Mon, 24 Mar 2014 02:30:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=2JinIHNDZDHIjaMWnvH+ZoIlkLTk6EsaYKLImc7ILPc=; b=I3//b5t6vx2Qem4VDcucaVE9iPFH4YTFSBwNXLetmC2xtZ5EP1yPJUPMlbXnMcOAdw lzSVbeNlVo/e2mMFZ/b5tX0icmTAUm1y6ukl+gFnOOdRuAl62Ezar1hzKLDRkxwrCHER sldgZweyuQOaKuGR1gu5WuHRyQYb2fyKpv/RTyG5uhltzpZkv4wm7a95pXoNgJk2ujeK FqTqIfPNRnucC7s5pXlwaauD7xvVcLIFymSL8bfMYYg++Dcft243z6ay5hOqkkTgBnuT ya54uH+AQmWHK6nse5d1bmj15no6yqVKKaao3JAGCw1rI9NblaIYMRuBpsoT533x2zxC HTiQ== MIME-Version: 1.0 X-Received: by 10.224.5.136 with SMTP id 8mr75147294qav.42.1395653412587; Mon, 24 Mar 2014 02:30:12 -0700 (PDT) Received: by 10.140.86.104 with HTTP; Mon, 24 Mar 2014 02:30:12 -0700 (PDT) In-Reply-To: <532FE3B2.9060808@biereigel-wb.de> References: <532FE3B2.9060808@biereigel-wb.de> Date: Mon, 24 Mar 2014 17:30:12 +0800 Message-ID: Subject: Re: [REGRESSION 3.14-rc6] Samsung N150 lid does not "open" after suspend to RAM. From: Lan Tianyu To: Stefan Biereigel Cc: "linux-acpi@vger.kernel.org" , "linux-kernel@vger kernel org" , Stefan Biereigel , Len Brown , "Rafael J. Wysocki" Sender: linux-acpi-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-acpi@vger.kernel.org X-Spam-Status: No, score=-7.3 required=5.0 tests=BAYES_00, DKIM_ADSP_CUSTOM_MED, DKIM_SIGNED, FREEMAIL_FROM, RCVD_IN_DNSWL_HI, RP_MATCHES_RCVD, T_DKIM_INVALID, UNPARSEABLE_RELAY autolearn=unavailable version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP Please try the following patch. 2014-03-24 15:50 GMT+08:00 Stefan Biereigel : > Hi, > > starting with 3.14-rc6, the lid on my Samsung N150 behaves weird: My > system is set up, so that it should suspend to RAM as soon as the lid is > closed. Beginning with 3.14-rc6, the lid goes from "open" to "closed" > correctly the first time (and the system suspends), but after resuming > from standby (by opening the lid), the lid does not change to "open" again. > Of course, closing the lid again does not induce suspend to RAM then. > Opening the lid now (while not sleeping), makes ACPI notify the opening, > so I guess ACPI "misses" or discards the lid open event from the EC when > coming from sleep. > Now, closing the lid again does induce suspend to RAM. This behaviour is > reproducible: every other time, suspending works. > > This behaviour seems to be introduced by commit ad332c8a: ACPI / EC: > Clear stale EC events on Samsung systems. > Which was introduced after 3.14-rc5. > > When opening the lid to resume from standby, i see in dmesg: > Mar 23 22:12:04 little1 kernel: [ 7630.932074] ACPI : EC: 1 stale EC > events cleared > (which comes from drivers/acpi/ec.c) > > Seems to me, that the "open" event is cleared from the EC, but also > discarded instead of passed on. Shouldn't the correct behaviour be to > report all the pending events, read from the EC, as ACPI events? Can you > point me in a direction for fixing the issue cleanly, then I will try to > find a solution and prepare a patch for this issue. > > Best regards, > Stefan > > -- > To unsubscribe from this list: send the line "unsubscribe linux-acpi" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html diff --git a/drivers/acpi/ec.c b/drivers/acpi/ec.c index d7d32c2..9239527 100644 --- a/drivers/acpi/ec.c +++ b/drivers/acpi/ec.c @@ -1027,8 +1027,13 @@ static struct dmi_system_id ec_dmi_table[] __initdata = { DMI_MATCH(DMI_SYS_VENDOR, "ASUSTek Computer Inc."), DMI_MATCH(DMI_PRODUCT_NAME, "L4R"),}, NULL}, { - ec_clear_on_resume, "Samsung hardware", { - DMI_MATCH(DMI_SYS_VENDOR, "SAMSUNG ELECTRONICS CO., LTD.")}, NULL}, + ec_clear_on_resume, "Samsung NP530U3B", { + DMI_MATCH(DMI_SYS_VENDOR, "SAMSUNG ELECTRONICS CO., LTD."), + DMI_MATCH(DMI_PRODUCT_NAME, "530U3BI/530U4BI/530U4BH"),}, NULL}, + { + ec_clear_on_resume, "Samsung NP530U3C", { + DMI_MATCH(DMI_SYS_VENDOR, "SAMSUNG ELECTRONICS CO., LTD."), + DMI_MATCH(DMI_PRODUCT_NAME, "530U3C/530U4C/532U3C"),}, NULL}, {}, };