From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751258AbdE2QEK (ORCPT ); Mon, 29 May 2017 12:04:10 -0400 Received: from mx1.redhat.com ([209.132.183.28]:44610 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750811AbdE2QEI (ORCPT ); Mon, 29 May 2017 12:04:08 -0400 DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com A86B53DFCD Authentication-Results: ext-mx05.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx05.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=benjamin.tissoires@redhat.com DKIM-Filter: OpenDKIM Filter v2.11.0 mx1.redhat.com A86B53DFCD Date: Mon, 29 May 2017 18:04:00 +0200 From: Benjamin Tissoires To: Lv Zheng Cc: "Rafael J. Wysocki" , "Rafael J. Wysocki" , Len Brown , Lv Zheng , linux-kernel@vger.kernel.org, linux-acpi@vger.kernel.org, systemd-devel@lists.freedesktop.org, Peter Hutterer Subject: Re: [RFC PATCH v3 1/5] ACPI: button: Add indication of BIOS notification and faked events Message-ID: <20170529160400.GA28287@mail.corp.redhat.com> References: <2a779ae8c280c968b3237ac4a3d9580df7262a46.1493951798.git.lv.zheng@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.29]); Mon, 29 May 2017 16:04:08 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Lv, On May 27 2017 or thereabouts, Lv Zheng wrote: > This patch adds a parameter to acpi_lid_notify_state() so that it can act > differently against BIOS notification and kernel faked events. > > Cc: > Cc: Benjamin Tissoires > Cc: Peter Hutterer > Signed-off-by: Lv Zheng > --- Answering to this one for the entire series: last week was a mix of public holidays and PTO from me. I was only able to review this series today, so sorry for the delay. I still have a feeling this driver is far too engineered for a simple input node. There are internal states, defers, mangle of events and too many kernel parameters. I still need to get my head around it, but the more I think of it, the more I think the solution provided by Lennart in https://github.com/systemd/systemd/issues/2807 is the simplest one: when we are not sure about the state of the LID switch because _LID might be wrong, we shouldn't export a LID input node. Which means that all broken cases would be fixed by just a quirk "unreliable lid switch". Give me a day or two to get this in a better shape. Cheers, Benjamin