[Public]
Hi,
The firmware on some OEM laptops with AMD SOCs advertise that they have sensors connected to AMD SFH but they really don't physically have them. In 5.19 a commit has gone in that discovers this case and prevents the driver from advertising this sensor to userspace. This might not seem like a big deal to have sensors advertised that aren't really there, but AMD has observed that specifically on orientation sensors the random garbage data associated can cause userspace to interpret a screen rotation during resume from suspend.
As GNOME has a daemon running that interprets these events I've seen first hand that it can cause the display go upside down without a lot of recourse other than command line tools or rebooting.
Can you please backport this commit to 5.15.y+ and later to fix this: commit b5d7f43e97dabfa04a4be5ff027ce7da119332be ("HID: amd_sfh: Add support for sensor discovery")
Thanks,
On Wed, May 25, 2022 at 07:23:59PM +0000, Limonciello, Mario wrote:
[Public]
Hi,
The firmware on some OEM laptops with AMD SOCs advertise that they have sensors connected to AMD SFH but they really don't physically have them. In 5.19 a commit has gone in that discovers this case and prevents the driver from advertising this sensor to userspace. This might not seem like a big deal to have sensors advertised that aren't really there, but AMD has observed that specifically on orientation sensors the random garbage data associated can cause userspace to interpret a screen rotation during resume from suspend.
As GNOME has a daemon running that interprets these events I've seen first hand that it can cause the display go upside down without a lot of recourse other than command line tools or rebooting.
Can you please backport this commit to 5.15.y+ and later to fix this: commit b5d7f43e97dabfa04a4be5ff027ce7da119332be ("HID: amd_sfh: Add support for sensor discovery")
How queued up, thanks.
greg k-h
linux-stable-mirror@lists.linaro.org