linux-kernel - RE: [PATCH v3 1/3] ACPI / button: Remove initial lid state notification

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 23 Jun 2016 00:57:20 +0000
From:	"Zheng, Lv" <lv.zheng@...el.com>
To:	"Rafael J. Wysocki" <rjw@...ysocki.net>
CC:	"Wysocki, Rafael J" <rafael.j.wysocki@...el.com>,
	"Brown, Len" <len.brown@...el.com>, Lv Zheng <zetalog@...il.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-acpi@...r.kernel.org" <linux-acpi@...r.kernel.org>
Subject: RE: [PATCH v3 1/3] ACPI / button: Remove initial lid state
 notification

Hi, Rafael

> From: Rafael J. Wysocki [mailto:rjw@...ysocki.net]
> Subject: Re: [PATCH v3 1/3] ACPI / button: Remove initial lid state
> notification
> 
> On Wednesday, June 01, 2016 06:10:34 PM Lv Zheng wrote:
> > 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 the
> lid
> > state upon the last lid notification instead of returning the lid state
> > upon the last _LID evaluation. There won't be difference when the _LID
> > control method is evaluated during the runtime, the problem is its initial
> > returning value. When the BIOSen implement this control method with
> cached
> > value, the initial returning value is likely not reliable. There are simply
> > so many examples retuning "close" as initial lid state (Link 1), sending
> > this state to the userspace causes suspending right after
> booting/resuming.
> >
> > Since the lid state is implemented by the BIOSen, the kernel lid driver has
> > no idea how it can be correct, this patch stops sending the initial lid
> > state to the userspace to try to avoid sending the wrong lid state to the
> > userspace to trigger such kind of wrong suspending. This actually reverts
> > the following commit introduced for fixing a novell bug (Link 2):
> >   Commit: 23de5d9ef2a4bbc4f733f58311bcb7cf6239c813
> >   Subject: ACPI: button: send initial lid state after add and resume
> >
> > Link 1: 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
> > Link 2: https://bugzilla.novell.com/show_bug.cgi?id=326814
> > Signed-off-by: Lv Zheng <lv.zheng@...el.com>
> 
> I've applied [1-3/3] from this series, but I'm not sure if the last patch
> is the latest version.  Can you please verify in linux-next?

[Lv Zheng] 
I confirmed, the patch in linux-next is the latest version.

And just for your information.
I still have things to do with the lid driver to address Bastien and Benjamin's request:
1. ABI documentation
2. new key event ABI for acpi lid close event (for example, PM_LID)
That's not related to this quirk.
And I'll go back to that after I finish my current pending work.

Thanks and best regards
-Lv