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 for Android: free password hash cracker in your pocket
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Date:   Thu, 15 Dec 2022 13:16:14 -0600
From:   Mario Limonciello <mario.limonciello@....com>
To:     <rafael@...nel.org>, Philipp Zabel <philipp.zabel@...il.com>,
        "Mario Limonciello" <mario.limonciello@....com>,
        "Rafael J. Wysocki" <rafael.j.wysocki@...el.com>
CC:     <anson.tsao@....com>, <ben@...eng.me>, <paul@...pog.com>,
        <bilkow@...anota.com>, <Shyam-sundar.S-k@....com>,
        Len Brown <lenb@...nel.org>, <linux-acpi@...r.kernel.org>,
        <linux-kernel@...r.kernel.org>
Subject: [PATCH 0/2] Stop using AMD GUID/_REV 2 by default

A number of laptops have been showing up where lots of EC controlled
features weren't working after resume.  They've varied from KBD
backlight, to fans, brightness control and lots more.
In kernel 6.1 we introduced a module parameter through
commit a0bc002393d4 ("ACPI: x86: s2idle: Add module parameter to
prefer Microsoft GUID") and a series of quirks in follow up commits
for systems that people reported the problems.

3 more systems recently reported issues; and so rather than increasing
the list /again/ to add these new systems we took a hard look at the
"why".

The AMD GUID/_REV 2 path was introduced for vendors to be able to
differentiate from the Microsoft path.  Vendors could populate this
with unique code for their designs.  Conceptually this was supposed
to help the ecosystem, however in practice we've found that there
are more machines that don't populate it than do.

The only models that have populated this with unique code for avoiding
a bug specific to their design is the HP Elitebook 835, 845, and 865 G9
systems.

To avoid growing the list further this series rips out the module
parameter support, all the quirks and sets the default policy to follow
the Microsoft GUID path for AMD Rembrandt or later.  We validated this
on OEM systems and we found this fixes them.

To avoid regressing the HP systems that use the AMD GUID/_REV 2
path, let them keep taking it. The reason they take it is believed to
be a bug with WLAN firmware.  If this is fixed in the future, we may
consider dropping the HP systems as well and having no quirks.

Mario Limonciello (2):
  ACPI: x86: s2idle: Force AMD GUID/_REV 2 on HP Elitebook 865
  ACPI: x86: s2idle: Stop using AMD specific codepath for Rembrandt+

 drivers/acpi/x86/s2idle.c | 87 ++++++---------------------------------
 1 file changed, 13 insertions(+), 74 deletions(-)

-- 
2.34.1

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ