From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753477AbcESB72 (ORCPT ); Wed, 18 May 2016 21:59:28 -0400 Received: from mga14.intel.com ([192.55.52.115]:39496 "EHLO mga14.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751807AbcESB70 (ORCPT ); Wed, 18 May 2016 21:59:26 -0400 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.26,332,1459839600"; d="scan'208";a="984162981" From: "Zheng, Lv" To: Bastien Nocera , "Wysocki, Rafael J" , "Rafael J. Wysocki" , "Brown, Len" CC: Lv Zheng , "linux-kernel@vger.kernel.org" , "linux-acpi@vger.kernel.org" Subject: RE: [RFC PATCH 1/2] ACPI / button: Send "open" state after boot/resume Thread-Topic: [RFC PATCH 1/2] ACPI / button: Send "open" state after boot/resume Thread-Index: AQHRsBYB8xemC1B1zEarXnGmeP5mt5++I1AAgAFeVmA= Date: Thu, 19 May 2016 01:59:21 +0000 Message-ID: <1AE640813FDE7649BE1B193DEA596E883BBA30A5@SHSMSX101.ccr.corp.intel.com> References: <1463576234.3440.25.camel@hadess.net> In-Reply-To: <1463576234.3440.25.camel@hadess.net> Accept-Language: zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiOTU0NmIwOTktYTc0ZC00ZDkyLThiNWQtOWNiNGJhMTI2ZjBhIiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX0lDIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE1LjkuNi42IiwiVHJ1c3RlZExhYmVsSGFzaCI6Ik1oeFI1cWNGSFg3YUNYSEpoZytFRXNtNmtnUXR3UlYwcWc5NnA4UjJKNmM9In0= x-ctpclassification: CTP_IC x-originating-ip: [10.239.127.40] Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by mail.home.local id u4J1xXU5031335 Hi, > From: Bastien Nocera [mailto:hadess@hadess.net] > Subject: Re: [RFC PATCH 1/2] ACPI / button: Send "open" state after > boot/resume > > On Tue, 2016-05-17 at 16:27 +0800, Lv Zheng wrote: > > (This patch hasn't been tested, it's sent for comments) > > > > Linux userspace (systemd-logind) keeps on rechecking lid state when the > > lid state is closed. If it failed to update the lid state to open after > > boot/resume, it could suspend the system. But as: > > 1. Traditional ACPI platform may not generate the lid open event after > >    resuming as the open event is actually handled by the BIOS and the system > >    is then resumed from a FACS vector. > > 2. The _LID control method's initial returning value is not reliable. The > >    _LID control method is described to return the "current" lid state, > >    however the word of "current" has ambiguity, many BIOSen return lid > >    state upon last lid notification while the developers may think the > >    BIOSen should always return the lid state upon last _LID evaluation. > >    There won't be difference when we evaluate _LID during the runtime, the > >    problem is the initial returning value of this function. When the BIOSen > >    implement this control method with cached value, the initial returning > >    value is likely not reliable. > > Thus there is no mean for the ACPI lid driver to provide such an event > > conveying correct current lid state. When there is no such an event or the > > event conveys wrong result, false suspending can be examined. > > > > The root cause of the issue is systemd itself, it could handle the ACPI > > control method lid device by implementing a special option like > > LidSwitchLevelTriggered=False when it detected the ACPI lid device. However > > there is no explicit documentation clarified the ambiguity, we need to > > work it around in the kernel before systemd changing its mind. > > > > Link 1: https://lkml.org/2016/3/7/460 > > Link 2: https://github.com/systemd/systemd/issues/2087 > > Link 3: https://bugzilla.kernel.org/show_bug.cgi?id=89211 > >         https://bugzilla.kernel.org/show_bug.cgi?id=106151 > >         https://bugzilla.kernel.org/show_bug.cgi?id=106941 > > Signed-off-by: Lv Zheng > > Cc: Bastien Nocera: > > As mentioned previously, I'd be much happier if either: > - a new system was put in place that matched the ACPI specs and the way > they are used by Windows [Lv Zheng] Then what about the old systems? Surface Pro 1 and Surface 3 are MS platforms that should have already adapted to the Windows. They are currently suffering from the same issue by running Linux. > - an additional tag/property was added to show that the API offered by > the LID switch is different from the one that existing since ACPI > support was added to Linux. > > And I'd really appreciate it if you stopped saying that it's systemd's > fault. [Lv Zheng] OK. Instead of saying this is a fault, I'll say systemd may need an additional option to handle ACPI lid device. > > The kernel has offered an API to user-space that included the state of > the LID switch. And the state of the LID switch has been correct for > the majority of systems and devices for the past decade or so. The fact > that this device means that the LID state isn't reliable anymore means > that the kernel needs to communicate that to user-space. > > I'm volunteering to modify systemd and UPower to respect the fact that > the LID switch state isn't available on those devices. If you want to > find something to blame, blame the kernel for implementing an API that > doesn't reflect what the hardware makes available. Though you can only > say that with the benefit of hindsight. > > So, NAK from me. [Lv Zheng] I'm out of the context here. This patch is generated to respect the current systemd behavior. If not, we'd rather just delete the 2 wrong lines. I know that you need a documentation clarification, we are putting effort on this. Thanks and best regards -Lv