linux-kernel - RE: [PATCH v2 3/3] ACPI / button: Send "open" state after boot/resume

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]

Message-ID: <1AE640813FDE7649BE1B193DEA596E883BBB71A8@SHSMSX101.ccr.corp.intel.com>
Date:	Wed, 1 Jun 2016 07:51:05 +0000
From:	"Zheng, Lv" <lv.zheng@...el.com>
To:	"Zheng, Lv" <lv.zheng@...el.com>,
	Benjamin Tissoires <benjamin.tissoires@...il.com>
CC:	"Wysocki, Rafael J" <rafael.j.wysocki@...el.com>,
	"Rafael J. Wysocki" <rjw@...ysocki.net>,
	"Brown, Len" <len.brown@...el.com>, Lv Zheng <zetalog@...il.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	ACPI Devel Maling List <linux-acpi@...r.kernel.org>,
	"Bastien Nocera:" <hadess@...ess.net>,
	"Valdis.Kletnieks@...edu" <Valdis.Kletnieks@...edu>
Subject: RE: [PATCH v2 3/3] ACPI / button: Send "open" state after
 boot/resume

Hi,

[cut]
> > We could have a parameter (say "send_lid_open_on_resume" or
> > "use_bios_lid_value") in acpi/button.c which would allow people to
> > choose if they want the "new" behavior or the old one. And we could
> > also add some DMI matching for the messed up laptops/tablets where
> we
> > force one or the other quirk. When we agree that user space now
> > behaves gently with us, we could then remove entirely the quirk and
> > the dmi matching.
> >
> > How does that sound?
> [Lv Zheng]
> The choices are in my first revision.
> I could restore it back and re-send this series.
> Also I need to update PATCH 02 to eliminate wrong IS_ERR_VALUE().
[Lv Zheng] 
I forgot to mention.
IMO, if the issue is because of uncertain gaps, not a confirmed BIOS bug, or a confirmed gap that has to be solved in a spirit of compromise, we should not add quirks.
We could just provide boot parameters for users to choose.
Because the quirk table could grow bigger and bigger, exceeding our control.

So I probably would just implement the parameter part, without adding the DMI entries.

Thanks and best regards
-Lv