<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux-stable.git/drivers/platform, branch v6.6.3</title>
<subtitle>Linux kernel stable tree</subtitle>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/'/>
<entry>
<title>platform/x86: thinkpad_acpi: Add battery quirk for Thinkpad X120e</title>
<updated>2023-11-28T17:19:39+00:00</updated>
<author>
<name>Olli Asikainen</name>
<email>olli.asikainen@gmail.com</email>
</author>
<published>2023-10-24T19:09:21+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=9d43c83cd8621322442b2da084243f442f21a273'/>
<id>9d43c83cd8621322442b2da084243f442f21a273</id>
<content type='text'>
[ Upstream commit 916646758aea81a143ce89103910f715ed923346 ]

Thinkpad X120e also needs this battery quirk.

Signed-off-by: Olli Asikainen &lt;olli.asikainen@gmail.com&gt;
Link: https://lore.kernel.org/r/20231024190922.2742-1-olli.asikainen@gmail.com
Reviewed-by: Ilpo Järvinen &lt;ilpo.jarvinen@linux.intel.com&gt;
Signed-off-by: Ilpo Järvinen &lt;ilpo.jarvinen@linux.intel.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ Upstream commit 916646758aea81a143ce89103910f715ed923346 ]

Thinkpad X120e also needs this battery quirk.

Signed-off-by: Olli Asikainen &lt;olli.asikainen@gmail.com&gt;
Link: https://lore.kernel.org/r/20231024190922.2742-1-olli.asikainen@gmail.com
Reviewed-by: Ilpo Järvinen &lt;ilpo.jarvinen@linux.intel.com&gt;
Signed-off-by: Ilpo Järvinen &lt;ilpo.jarvinen@linux.intel.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>platform/chrome: kunit: initialize lock for fake ec_dev</title>
<updated>2023-11-28T17:19:39+00:00</updated>
<author>
<name>Tzung-Bi Shih</name>
<email>tzungbi@kernel.org</email>
</author>
<published>2023-10-03T08:05:04+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=20bcab576168792c4127105b8f54d2e9484448e7'/>
<id>20bcab576168792c4127105b8f54d2e9484448e7</id>
<content type='text'>
[ Upstream commit e410b4ade83d06a046f6e32b5085997502ba0559 ]

cros_ec_cmd_xfer() uses ec_dev-&gt;lock.  Initialize it.

Otherwise, dmesg shows the following:
&gt; DEBUG_LOCKS_WARN_ON(lock-&gt;magic != lock)
&gt; ...
&gt; Call Trace:
&gt;  ? __mutex_lock
&gt;  ? __warn
&gt;  ? __mutex_lock
&gt;  ...
&gt;  ? cros_ec_cmd_xfer

Reviewed-by: Guenter Roeck &lt;groeck@chromium.org&gt;
Link: https://lore.kernel.org/r/20231003080504.4011337-1-tzungbi@kernel.org
Signed-off-by: Tzung-Bi Shih &lt;tzungbi@kernel.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ Upstream commit e410b4ade83d06a046f6e32b5085997502ba0559 ]

cros_ec_cmd_xfer() uses ec_dev-&gt;lock.  Initialize it.

Otherwise, dmesg shows the following:
&gt; DEBUG_LOCKS_WARN_ON(lock-&gt;magic != lock)
&gt; ...
&gt; Call Trace:
&gt;  ? __mutex_lock
&gt;  ? __warn
&gt;  ? __mutex_lock
&gt;  ...
&gt;  ? cros_ec_cmd_xfer

Reviewed-by: Guenter Roeck &lt;groeck@chromium.org&gt;
Link: https://lore.kernel.org/r/20231003080504.4011337-1-tzungbi@kernel.org
Signed-off-by: Tzung-Bi Shih &lt;tzungbi@kernel.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>platform/chrome: cros_ec_lpc: Separate host command and irq disable</title>
<updated>2023-11-20T10:59:08+00:00</updated>
<author>
<name>Lalith Rajendran</name>
<email>lalithkraj@chromium.org</email>
</author>
<published>2023-10-27T21:02:22+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=5eafd56d0992eeebd3df3a8f25a2583e6ddad0dc'/>
<id>5eafd56d0992eeebd3df3a8f25a2583e6ddad0dc</id>
<content type='text'>
[ Upstream commit 47ea0ddb1f5604ba3496baa19110aec6a3151f2e ]

Both cros host command and irq disable were moved to suspend
prepare stage from late suspend recently. This is causing EC
to report MKBP event timeouts during suspend stress testing.
When the MKBP event timeouts happen during suspend, subsequent
wakeup of AP by EC using MKBP doesn't happen properly. Move the
irq disabling part back to late suspend stage which is a general
suggestion from the suspend kernel documentaiton to do irq
disable as late as possible.

Fixes: 4b9abbc132b8 ("platform/chrome: cros_ec_lpc: Move host command to prepare/complete")
Signed-off-by: Lalith Rajendran &lt;lalithkraj@chromium.org&gt;
Link: https://lore.kernel.org/r/20231027160221.v4.1.I1725c3ed27eb7cd9836904e49e8bfa9fb0200a97@changeid
Signed-off-by: Tzung-Bi Shih &lt;tzungbi@kernel.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ Upstream commit 47ea0ddb1f5604ba3496baa19110aec6a3151f2e ]

Both cros host command and irq disable were moved to suspend
prepare stage from late suspend recently. This is causing EC
to report MKBP event timeouts during suspend stress testing.
When the MKBP event timeouts happen during suspend, subsequent
wakeup of AP by EC using MKBP doesn't happen properly. Move the
irq disabling part back to late suspend stage which is a general
suggestion from the suspend kernel documentaiton to do irq
disable as late as possible.

Fixes: 4b9abbc132b8 ("platform/chrome: cros_ec_lpc: Move host command to prepare/complete")
Signed-off-by: Lalith Rajendran &lt;lalithkraj@chromium.org&gt;
Link: https://lore.kernel.org/r/20231027160221.v4.1.I1725c3ed27eb7cd9836904e49e8bfa9fb0200a97@changeid
Signed-off-by: Tzung-Bi Shih &lt;tzungbi@kernel.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>platform/x86: wmi: Fix opening of char device</title>
<updated>2023-11-20T10:59:07+00:00</updated>
<author>
<name>Armin Wolf</name>
<email>W_Armin@gmx.de</email>
</author>
<published>2023-10-20T21:10:04+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=fb7b06b59c6887659c6ed0ecd3110835eecbb6a3'/>
<id>fb7b06b59c6887659c6ed0ecd3110835eecbb6a3</id>
<content type='text'>
[ Upstream commit eba9ac7abab91c8f6d351460239108bef5e7a0b6 ]

Since commit fa1f68db6ca7 ("drivers: misc: pass miscdevice pointer via
file private data"), the miscdevice stores a pointer to itself inside
filp-&gt;private_data, which means that private_data will not be NULL when
wmi_char_open() is called. This might cause memory corruption should
wmi_char_open() be unable to find its driver, something which can
happen when the associated WMI device is deleted in wmi_free_devices().

Fix the problem by using the miscdevice pointer to retrieve the WMI
device data associated with a char device using container_of(). This
also avoids wmi_char_open() picking a wrong WMI device bound to a
driver with the same name as the original driver.

Fixes: 44b6b7661132 ("platform/x86: wmi: create userspace interface for drivers")
Signed-off-by: Armin Wolf &lt;W_Armin@gmx.de&gt;
Link: https://lore.kernel.org/r/20231020211005.38216-5-W_Armin@gmx.de
Reviewed-by: Ilpo Järvinen &lt;ilpo.jarvinen@linux.intel.com&gt;
Signed-off-by: Ilpo Järvinen &lt;ilpo.jarvinen@linux.intel.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ Upstream commit eba9ac7abab91c8f6d351460239108bef5e7a0b6 ]

Since commit fa1f68db6ca7 ("drivers: misc: pass miscdevice pointer via
file private data"), the miscdevice stores a pointer to itself inside
filp-&gt;private_data, which means that private_data will not be NULL when
wmi_char_open() is called. This might cause memory corruption should
wmi_char_open() be unable to find its driver, something which can
happen when the associated WMI device is deleted in wmi_free_devices().

Fix the problem by using the miscdevice pointer to retrieve the WMI
device data associated with a char device using container_of(). This
also avoids wmi_char_open() picking a wrong WMI device bound to a
driver with the same name as the original driver.

Fixes: 44b6b7661132 ("platform/x86: wmi: create userspace interface for drivers")
Signed-off-by: Armin Wolf &lt;W_Armin@gmx.de&gt;
Link: https://lore.kernel.org/r/20231020211005.38216-5-W_Armin@gmx.de
Reviewed-by: Ilpo Järvinen &lt;ilpo.jarvinen@linux.intel.com&gt;
Signed-off-by: Ilpo Järvinen &lt;ilpo.jarvinen@linux.intel.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>platform/x86: wmi: Fix probe failure when failing to register WMI devices</title>
<updated>2023-11-20T10:59:07+00:00</updated>
<author>
<name>Armin Wolf</name>
<email>W_Armin@gmx.de</email>
</author>
<published>2023-10-20T21:10:03+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=328d67254df48ffefd8be423b39d71b6edb526c8'/>
<id>328d67254df48ffefd8be423b39d71b6edb526c8</id>
<content type='text'>
[ Upstream commit ed85891a276edaf7a867de0e9acd0837bc3008f2 ]

When a WMI device besides the first one somehow fails to register,
retval is returned while still containing a negative error code. This
causes the ACPI device fail to probe, leaving behind zombie WMI devices
leading to various errors later.

Handle the single error path separately and return 0 unconditionally
after trying to register all WMI devices to solve the issue. Also
continue to register WMI devices even if some fail to allocate memory.

Fixes: 6ee50aaa9a20 ("platform/x86: wmi: Instantiate all devices before adding them")
Signed-off-by: Armin Wolf &lt;W_Armin@gmx.de&gt;
Link: https://lore.kernel.org/r/20231020211005.38216-4-W_Armin@gmx.de
Reviewed-by: Ilpo Järvinen &lt;ilpo.jarvinen@linux.intel.com&gt;
Signed-off-by: Ilpo Järvinen &lt;ilpo.jarvinen@linux.intel.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ Upstream commit ed85891a276edaf7a867de0e9acd0837bc3008f2 ]

When a WMI device besides the first one somehow fails to register,
retval is returned while still containing a negative error code. This
causes the ACPI device fail to probe, leaving behind zombie WMI devices
leading to various errors later.

Handle the single error path separately and return 0 unconditionally
after trying to register all WMI devices to solve the issue. Also
continue to register WMI devices even if some fail to allocate memory.

Fixes: 6ee50aaa9a20 ("platform/x86: wmi: Instantiate all devices before adding them")
Signed-off-by: Armin Wolf &lt;W_Armin@gmx.de&gt;
Link: https://lore.kernel.org/r/20231020211005.38216-4-W_Armin@gmx.de
Reviewed-by: Ilpo Järvinen &lt;ilpo.jarvinen@linux.intel.com&gt;
Signed-off-by: Ilpo Järvinen &lt;ilpo.jarvinen@linux.intel.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>platform/x86: Add s2idle quirk for more Lenovo laptops</title>
<updated>2023-10-27T14:42:12+00:00</updated>
<author>
<name>David Lazar</name>
<email>dlazar@gmail.com</email>
</author>
<published>2023-10-25T19:30:16+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=3bde7ec13c971445faade32172cb0b4370b841d9'/>
<id>3bde7ec13c971445faade32172cb0b4370b841d9</id>
<content type='text'>
When suspending to idle and resuming on some Lenovo laptops using the
Mendocino APU, multiple NVME IOMMU page faults occur, showing up in
dmesg as repeated errors:

nvme 0000:01:00.0: AMD-Vi: Event logged [IO_PAGE_FAULT domain=0x000b
address=0xb6674000 flags=0x0000]

The system is unstable afterwards.

Applying the s2idle quirk introduced by commit 455cd867b85b ("platform/x86:
thinkpad_acpi: Add a s2idle resume quirk for a number of laptops")
allows these systems to work with the IOMMU enabled and s2idle
resume to work.

Closes: https://bugzilla.kernel.org/show_bug.cgi?id=218024
Suggested-by: Mario Limonciello &lt;mario.limonciello@amd.com&gt;
Suggested-by: Mark Pearson &lt;mpearson-lenovo@squebb.ca&gt;
Signed-off-by: David Lazar &lt;dlazar@gmail.com&gt;
Reviewed-by: Mario Limonciello &lt;mario.limonciello@amd.com&gt;
Reviewed-by: Mark Pearson &lt;mpearson-lenovo@squebb.ca&gt;
Link: https://lore.kernel.org/r/ZTlsyOaFucF2pWrL@localhost
Signed-off-by: Hans de Goede &lt;hdegoede@redhat.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
When suspending to idle and resuming on some Lenovo laptops using the
Mendocino APU, multiple NVME IOMMU page faults occur, showing up in
dmesg as repeated errors:

nvme 0000:01:00.0: AMD-Vi: Event logged [IO_PAGE_FAULT domain=0x000b
address=0xb6674000 flags=0x0000]

The system is unstable afterwards.

Applying the s2idle quirk introduced by commit 455cd867b85b ("platform/x86:
thinkpad_acpi: Add a s2idle resume quirk for a number of laptops")
allows these systems to work with the IOMMU enabled and s2idle
resume to work.

Closes: https://bugzilla.kernel.org/show_bug.cgi?id=218024
Suggested-by: Mario Limonciello &lt;mario.limonciello@amd.com&gt;
Suggested-by: Mark Pearson &lt;mpearson-lenovo@squebb.ca&gt;
Signed-off-by: David Lazar &lt;dlazar@gmail.com&gt;
Reviewed-by: Mario Limonciello &lt;mario.limonciello@amd.com&gt;
Reviewed-by: Mark Pearson &lt;mpearson-lenovo@squebb.ca&gt;
Link: https://lore.kernel.org/r/ZTlsyOaFucF2pWrL@localhost
Signed-off-by: Hans de Goede &lt;hdegoede@redhat.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>platform/mellanox: mlxbf-tmfifo: Fix a warning message</title>
<updated>2023-10-18T13:38:09+00:00</updated>
<author>
<name>Liming Sun</name>
<email>limings@nvidia.com</email>
</author>
<published>2023-10-12T23:02:35+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=99c09c985e5973c8f0ad976ebae069548dd86f12'/>
<id>99c09c985e5973c8f0ad976ebae069548dd86f12</id>
<content type='text'>
This commit fixes the smatch static checker warning in function
mlxbf_tmfifo_rxtx_word() which complains data not initialized at
line 634 when IS_VRING_DROP() is TRUE.

Signed-off-by: Liming Sun &lt;limings@nvidia.com&gt;
Link: https://lore.kernel.org/r/20231012230235.219861-1-limings@nvidia.com
Reviewed-by: Hans de Goede &lt;hdegoede@redhat.com&gt;
Signed-off-by: Hans de Goede &lt;hdegoede@redhat.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This commit fixes the smatch static checker warning in function
mlxbf_tmfifo_rxtx_word() which complains data not initialized at
line 634 when IS_VRING_DROP() is TRUE.

Signed-off-by: Liming Sun &lt;limings@nvidia.com&gt;
Link: https://lore.kernel.org/r/20231012230235.219861-1-limings@nvidia.com
Reviewed-by: Hans de Goede &lt;hdegoede@redhat.com&gt;
Signed-off-by: Hans de Goede &lt;hdegoede@redhat.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>apple-gmux: Hard Code max brightness for MMIO gmux</title>
<updated>2023-10-18T13:33:24+00:00</updated>
<author>
<name>Orlando Chamberlain</name>
<email>orlandoch.dev@gmail.com</email>
</author>
<published>2023-10-17T11:14:45+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=0e51cb42438b8754d8f4cee4c802a8c5bb2cd5e0'/>
<id>0e51cb42438b8754d8f4cee4c802a8c5bb2cd5e0</id>
<content type='text'>
The data in the max brightness port for iMacs with MMIO gmux incorrectly
reports 0x03ff, but it should be 0xffff. As all other MMIO gmux models
have 0xffff, hard code this for all MMIO gmux's so they all have the
proper brightness range accessible.

Fixes: 0c18184de990 ("platform/x86: apple-gmux: support MMIO gmux on T2 Macs")
Reported-by: Karsten Leipold &lt;poldi@dfn.de&gt;
Signed-off-by: Orlando Chamberlain &lt;orlandoch.dev@gmail.com&gt;
Link: https://lore.kernel.org/r/20231017111444.19304-2-orlandoch.dev@gmail.com
Reviewed-by: Hans de Goede &lt;hdegoede@redhat.com&gt;
Signed-off-by: Hans de Goede &lt;hdegoede@redhat.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
The data in the max brightness port for iMacs with MMIO gmux incorrectly
reports 0x03ff, but it should be 0xffff. As all other MMIO gmux models
have 0xffff, hard code this for all MMIO gmux's so they all have the
proper brightness range accessible.

Fixes: 0c18184de990 ("platform/x86: apple-gmux: support MMIO gmux on T2 Macs")
Reported-by: Karsten Leipold &lt;poldi@dfn.de&gt;
Signed-off-by: Orlando Chamberlain &lt;orlandoch.dev@gmail.com&gt;
Link: https://lore.kernel.org/r/20231017111444.19304-2-orlandoch.dev@gmail.com
Reviewed-by: Hans de Goede &lt;hdegoede@redhat.com&gt;
Signed-off-by: Hans de Goede &lt;hdegoede@redhat.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>platform/surface: platform_profile: Propagate error if profile registration fails</title>
<updated>2023-10-18T13:30:54+00:00</updated>
<author>
<name>Armin Wolf</name>
<email>W_Armin@gmx.de</email>
</author>
<published>2023-10-14T23:54:49+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=fe0e04cf66a12ffe6d1b43725ddaabd5599d024f'/>
<id>fe0e04cf66a12ffe6d1b43725ddaabd5599d024f</id>
<content type='text'>
If platform_profile_register() fails, the driver does not propagate
the error, but instead probes successfully. This means when the driver
unbinds, the a warning might be issued by platform_profile_remove().

Fix this by propagating the error back to the caller of
surface_platform_profile_probe().

Compile-tested only.

Fixes: b78b4982d763 ("platform/surface: Add platform profile driver")
Signed-off-by: Armin Wolf &lt;W_Armin@gmx.de&gt;
Reviewed-by: Maximilian Luz &lt;luzmaximilian@gmail.com&gt;
Tested-by: Maximilian Luz &lt;luzmaximilian@gmail.com&gt;
Link: https://lore.kernel.org/r/20231014235449.288702-1-W_Armin@gmx.de
Signed-off-by: Hans de Goede &lt;hdegoede@redhat.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
If platform_profile_register() fails, the driver does not propagate
the error, but instead probes successfully. This means when the driver
unbinds, the a warning might be issued by platform_profile_remove().

Fix this by propagating the error back to the caller of
surface_platform_profile_probe().

Compile-tested only.

Fixes: b78b4982d763 ("platform/surface: Add platform profile driver")
Signed-off-by: Armin Wolf &lt;W_Armin@gmx.de&gt;
Reviewed-by: Maximilian Luz &lt;luzmaximilian@gmail.com&gt;
Tested-by: Maximilian Luz &lt;luzmaximilian@gmail.com&gt;
Link: https://lore.kernel.org/r/20231014235449.288702-1-W_Armin@gmx.de
Signed-off-by: Hans de Goede &lt;hdegoede@redhat.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>platform/x86: asus-wmi: Map 0x2a code, Ignore 0x2b and 0x2c events</title>
<updated>2023-10-18T09:58:42+00:00</updated>
<author>
<name>Hans de Goede</name>
<email>hdegoede@redhat.com</email>
</author>
<published>2023-10-17T09:07:25+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=235985d1763f7aba92c1c64e5f5aaec26c2c9b18'/>
<id>235985d1763f7aba92c1c64e5f5aaec26c2c9b18</id>
<content type='text'>
Newer Asus laptops send the following new WMI event codes when some
of the F1 - F12 "media" hotkeys are pressed:

0x2a Screen Capture
0x2b PrintScreen
0x2c CapsLock

Map 0x2a to KEY_SELECTIVE_SCREENSHOT mirroring how similar hotkeys
are mapped on other laptops.

PrintScreem and CapsLock are also reported as normal PS/2 keyboard events,
map these event codes to KE_IGNORE to avoid "Unknown key code 0x%x\n" log
messages.

Reported-by: James John &lt;me@donjajo.com&gt;
Closes: https://lore.kernel.org/platform-driver-x86/a2c441fe-457e-44cf-a146-0ecd86b037cf@donjajo.com/
Closes: https://bbs.archlinux.org/viewtopic.php?pid=2123716
Signed-off-by: Hans de Goede &lt;hdegoede@redhat.com&gt;
Link: https://lore.kernel.org/r/20231017090725.38163-4-hdegoede@redhat.com
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Newer Asus laptops send the following new WMI event codes when some
of the F1 - F12 "media" hotkeys are pressed:

0x2a Screen Capture
0x2b PrintScreen
0x2c CapsLock

Map 0x2a to KEY_SELECTIVE_SCREENSHOT mirroring how similar hotkeys
are mapped on other laptops.

PrintScreem and CapsLock are also reported as normal PS/2 keyboard events,
map these event codes to KE_IGNORE to avoid "Unknown key code 0x%x\n" log
messages.

Reported-by: James John &lt;me@donjajo.com&gt;
Closes: https://lore.kernel.org/platform-driver-x86/a2c441fe-457e-44cf-a146-0ecd86b037cf@donjajo.com/
Closes: https://bbs.archlinux.org/viewtopic.php?pid=2123716
Signed-off-by: Hans de Goede &lt;hdegoede@redhat.com&gt;
Link: https://lore.kernel.org/r/20231017090725.38163-4-hdegoede@redhat.com
</pre>
</div>
</content>
</entry>
</feed>
