linux-kernel - [REGRESSION 3.14-rc6] Samsung N150 lid does not "open" after suspend to RAM.

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-next>] [day] [month] [year] [list]

Message-ID: <532FE3B2.9060808@biereigel-wb.de>
Date:	Mon, 24 Mar 2014 08:50:10 +0100
From:	Stefan Biereigel <security@...reigel-wb.de>
To:	linux-acpi@...r.kernel.org, linux-kernel@...r.kernel.org
CC:	Stefan Biereigel <stefan@...reigel.de>, lenb@...nel.org,
	rjw@...ysocki.net
Subject: [REGRESSION 3.14-rc6] Samsung N150 lid does not "open" after suspend
 to RAM.

Hi,

starting with 3.14-rc6, the lid on my Samsung N150 behaves weird: My
system is set up, so that it should suspend to RAM as soon as the lid is
closed. Beginning with 3.14-rc6, the lid goes from "open" to "closed"
correctly the first time (and the system suspends), but after resuming
from standby (by opening the lid), the lid does not change to "open" again.
Of course, closing the lid again does not induce suspend to RAM then.
Opening the lid now (while not sleeping), makes ACPI notify the opening,
so I guess ACPI "misses" or discards the lid open event from the EC when
coming from sleep.
Now, closing the lid again does induce suspend to RAM. This behaviour is
reproducible: every other time, suspending works.

This behaviour seems to be introduced by commit ad332c8a: ACPI / EC:
Clear stale EC events on Samsung systems.
Which was introduced after 3.14-rc5.

When opening the lid to resume from standby, i see in dmesg:
Mar 23 22:12:04 little1 kernel: [ 7630.932074] ACPI : EC: 1 stale EC
events cleared
(which comes from drivers/acpi/ec.c)

Seems to me, that the "open" event is cleared from the EC, but also
discarded instead of passed on. Shouldn't the correct behaviour be to
report all the pending events, read from the EC, as ACPI events? Can you
point me in a direction for fixing the issue cleanly, then I will try to
find a solution and prepare a patch for this issue.

Best regards,
Stefan

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/