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]

Date:	Wed, 1 Jun 2016 10:07:40 +0200
From:	Benjamin Tissoires <benjamin.tissoires@...il.com>
To:	"Zheng, Lv" <lv.zheng@...el.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

On Wed, Jun 1, 2016 at 9:51 AM, Zheng, Lv <lv.zheng@...el.com> wrote:
> 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.
>

Works for me. I think in Fedora, we might default to keep the current
behavior, but document that some tablets need the parameter to be set.
As soon as systemd changes its policy, we can change the default
value.


As for the Surface3, I think the LID state and irq is just not enough
robust to be used through the ACPI node PNP0C0D. I get all the
information from the touchscreen ACPI Node and the WMI, so I think
there might be a way to remove the standard ACPI LID and use our own,
or simply override the ACPI call by a different one (through the WMI).
It's a shame logind only expects one LID event node :).

Cheers,
Benjamin