<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux.git/drivers/platform, branch v6.2-rc5</title>
<subtitle>Linux kernel source tree</subtitle>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/'/>
<entry>
<title>platform/x86: thinkpad_acpi: Fix profile mode display in AMT mode</title>
<updated>2023-01-13T10:40:30+00:00</updated>
<author>
<name>Mark Pearson</name>
<email>mpearson-lenovo@squebb.ca</email>
</author>
<published>2023-01-12T22:12:28+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=fde5f74ccfc771941b018b5415fa9664426e10ad'/>
<id>fde5f74ccfc771941b018b5415fa9664426e10ad</id>
<content type='text'>
Recently AMT mode was enabled (somewhat unexpectedly) on the Lenovo
Z13 platform. The FW is advertising it is available and the driver tries
to use it - unfortunately it reports the profile mode incorrectly.

Note, there is also some extra work needed to enable the dynamic aspect
of AMT support that I will be following up with; but more testing is
needed first. This patch just fixes things so the profiles are reported
correctly.

Link: https://gitlab.freedesktop.org/hadess/power-profiles-daemon/-/issues/115
Fixes: 46dcbc61b739 ("platform/x86: thinkpad-acpi: Add support for automatic mode transitions")

Reviewed-by: Mario Limonciello &lt;mario.limonciello@amd.com&gt;
Signed-off-by: Mark Pearson &lt;mpearson-lenovo@squebb.ca&gt;
Link: https://lore.kernel.org/r/20230112221228.490946-1-mpearson-lenovo@squebb.ca
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>
Recently AMT mode was enabled (somewhat unexpectedly) on the Lenovo
Z13 platform. The FW is advertising it is available and the driver tries
to use it - unfortunately it reports the profile mode incorrectly.

Note, there is also some extra work needed to enable the dynamic aspect
of AMT support that I will be following up with; but more testing is
needed first. This patch just fixes things so the profiles are reported
correctly.

Link: https://gitlab.freedesktop.org/hadess/power-profiles-daemon/-/issues/115
Fixes: 46dcbc61b739 ("platform/x86: thinkpad-acpi: Add support for automatic mode transitions")

Reviewed-by: Mario Limonciello &lt;mario.limonciello@amd.com&gt;
Signed-off-by: Mark Pearson &lt;mpearson-lenovo@squebb.ca&gt;
Link: https://lore.kernel.org/r/20230112221228.490946-1-mpearson-lenovo@squebb.ca
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/x86: int3472/discrete: Ensure the clk/power enable pins are in output mode</title>
<updated>2023-01-12T19:10:31+00:00</updated>
<author>
<name>Hans de Goede</name>
<email>hdegoede@redhat.com</email>
</author>
<published>2023-01-11T20:14:26+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=cf5ac2d45f6e4d11ad78e7b10ae9a4121ba5e995'/>
<id>cf5ac2d45f6e4d11ad78e7b10ae9a4121ba5e995</id>
<content type='text'>
acpi_get_and_request_gpiod() does not take a gpio_lookup_flags argument
specifying that the pins direction should be initialized to a specific
value.

This means that in some cases the pins might be left in input mode, causing
the gpiod_set() calls made to enable the clk / regulator to not work.

One example of this problem is the clk-enable GPIO for the ov01a1s sensor
on a Dell Latitude 9420 being left in input mode causing the clk to
never get enabled.

Explicitly set the direction of the pins to output to fix this.

Fixes: 5de691bffe57 ("platform/x86: Add intel_skl_int3472 driver")
Signed-off-by: Hans de Goede &lt;hdegoede@redhat.com&gt;
Reviewed-by: Andy Shevchenko &lt;andy@kernel.org&gt;
Reviewed-by: Daniel Scally &lt;djrscally@gmail.com&gt;
Reviewed-by: Sakari Ailus &lt;sakari.ailus@linux.intel.com&gt;
Link: https://lore.kernel.org/r/20230111201426.947853-1-hdegoede@redhat.com
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
acpi_get_and_request_gpiod() does not take a gpio_lookup_flags argument
specifying that the pins direction should be initialized to a specific
value.

This means that in some cases the pins might be left in input mode, causing
the gpiod_set() calls made to enable the clk / regulator to not work.

One example of this problem is the clk-enable GPIO for the ov01a1s sensor
on a Dell Latitude 9420 being left in input mode causing the clk to
never get enabled.

Explicitly set the direction of the pins to output to fix this.

Fixes: 5de691bffe57 ("platform/x86: Add intel_skl_int3472 driver")
Signed-off-by: Hans de Goede &lt;hdegoede@redhat.com&gt;
Reviewed-by: Andy Shevchenko &lt;andy@kernel.org&gt;
Reviewed-by: Daniel Scally &lt;djrscally@gmail.com&gt;
Reviewed-by: Sakari Ailus &lt;sakari.ailus@linux.intel.com&gt;
Link: https://lore.kernel.org/r/20230111201426.947853-1-hdegoede@redhat.com
</pre>
</div>
</content>
</entry>
<entry>
<title>platform/x86/amd: Fix refcount leak in amd_pmc_probe</title>
<updated>2023-01-12T19:04:38+00:00</updated>
<author>
<name>Miaoqian Lin</name>
<email>linmq006@gmail.com</email>
</author>
<published>2022-12-29T07:25:33+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=ccb32e2be14271a60e9ba89c6d5660cc9998773c'/>
<id>ccb32e2be14271a60e9ba89c6d5660cc9998773c</id>
<content type='text'>
pci_get_domain_bus_and_slot() takes reference, the caller should release
the reference by calling pci_dev_put() after use. Call pci_dev_put() in
the error path to fix this.

Fixes: 3d7d407dfb05 ("platform/x86: amd-pmc: Add support for AMD Spill to DRAM STB feature")
Signed-off-by: Miaoqian Lin &lt;linmq006@gmail.com&gt;
Reviewed-by: Mario Limonciello &lt;mario.limonciello@amd.com&gt;
Link: https://lore.kernel.org/r/20221229072534.1381432-1-linmq006@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>
pci_get_domain_bus_and_slot() takes reference, the caller should release
the reference by calling pci_dev_put() after use. Call pci_dev_put() in
the error path to fix this.

Fixes: 3d7d407dfb05 ("platform/x86: amd-pmc: Add support for AMD Spill to DRAM STB feature")
Signed-off-by: Miaoqian Lin &lt;linmq006@gmail.com&gt;
Reviewed-by: Mario Limonciello &lt;mario.limonciello@amd.com&gt;
Link: https://lore.kernel.org/r/20221229072534.1381432-1-linmq006@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/x86: intel/pmc/core: Add Meteor Lake mobile support</title>
<updated>2023-01-12T18:44:30+00:00</updated>
<author>
<name>Gayatri Kammela</name>
<email>gayatri.kammela@linux.intel.com</email>
</author>
<published>2022-12-28T23:05:53+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=6aa5207838ccf79879f212034435a5606f890eea'/>
<id>6aa5207838ccf79879f212034435a5606f890eea</id>
<content type='text'>
Add Meteor Lake mobile support to pmc core driver. Meteor Lake mobile
parts reuse all the Meteor Lake PCH IPs.

Cc: David E Box &lt;david.e.box@linux.intel.com&gt;
Signed-off-by: Gayatri Kammela &lt;gayatri.kammela@linux.intel.com&gt;
Link: https://lore.kernel.org/r/20221228230553.2497183-1-gayatri.kammela@linux.intel.com
Signed-off-by: Hans de Goede &lt;hdegoede@redhat.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Add Meteor Lake mobile support to pmc core driver. Meteor Lake mobile
parts reuse all the Meteor Lake PCH IPs.

Cc: David E Box &lt;david.e.box@linux.intel.com&gt;
Signed-off-by: Gayatri Kammela &lt;gayatri.kammela@linux.intel.com&gt;
Link: https://lore.kernel.org/r/20221228230553.2497183-1-gayatri.kammela@linux.intel.com
Signed-off-by: Hans de Goede &lt;hdegoede@redhat.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>platform/x86: simatic-ipc: add another model</title>
<updated>2023-01-12T18:42:53+00:00</updated>
<author>
<name>Henning Schild</name>
<email>henning.schild@siemens.com</email>
</author>
<published>2022-12-22T10:37:20+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=d348b1d761e358a4ba03fb34aa7e3dbd278db236'/>
<id>d348b1d761e358a4ba03fb34aa7e3dbd278db236</id>
<content type='text'>
Add IPC PX-39A support.

Signed-off-by: Henning Schild &lt;henning.schild@siemens.com&gt;
Link: https://lore.kernel.org/r/20221222103720.8546-3-henning.schild@siemens.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>
Add IPC PX-39A support.

Signed-off-by: Henning Schild &lt;henning.schild@siemens.com&gt;
Link: https://lore.kernel.org/r/20221222103720.8546-3-henning.schild@siemens.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/x86: simatic-ipc: correct name of a model</title>
<updated>2023-01-12T18:42:41+00:00</updated>
<author>
<name>Henning Schild</name>
<email>henning.schild@siemens.com</email>
</author>
<published>2022-12-22T10:37:19+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=ed058eab22d64c00663563e8e1e112989c65c59f'/>
<id>ed058eab22d64c00663563e8e1e112989c65c59f</id>
<content type='text'>
What we called IPC427G should be renamed to BX-39A to be more in line
with the actual product name.

Signed-off-by: Henning Schild &lt;henning.schild@siemens.com&gt;
Link: https://lore.kernel.org/r/20221222103720.8546-2-henning.schild@siemens.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>
What we called IPC427G should be renamed to BX-39A to be more in line
with the actual product name.

Signed-off-by: Henning Schild &lt;henning.schild@siemens.com&gt;
Link: https://lore.kernel.org/r/20221222103720.8546-2-henning.schild@siemens.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/x86: dell-privacy: Only register SW_CAMERA_LENS_COVER if present</title>
<updated>2023-01-12T18:40:19+00:00</updated>
<author>
<name>Hans de Goede</name>
<email>hdegoede@redhat.com</email>
</author>
<published>2022-12-21T22:07:24+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=6dc485f9940df8105ea729cbeb7a7d18d409dde5'/>
<id>6dc485f9940df8105ea729cbeb7a7d18d409dde5</id>
<content type='text'>
Unlike keys where userspace only reacts to keypresses, userspace may act
on switches in both (0 and 1) of their positions.

For example if a SW_TABLET_MODE switch is registered then GNOME will not
automatically show the onscreen keyboard when a text field gets focus on
touchscreen devices when SW_TABLET_MODE reports 0 and when SW_TABLET_MODE
reports 1 libinput will block (filter out) builtin keyboard and touchpad
events.

So to avoid unwanted side-effects EV_SW type inputs should only be
registered if they are actually present, only register SW_CAMERA_LENS_COVER
if it is actually there.

Fixes: 8af9fa37b8a3 ("platform/x86: dell-privacy: Add support for Dell hardware privacy")
Signed-off-by: Hans de Goede &lt;hdegoede@redhat.com&gt;
Link: https://lore.kernel.org/r/20221221220724.119594-2-hdegoede@redhat.com
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Unlike keys where userspace only reacts to keypresses, userspace may act
on switches in both (0 and 1) of their positions.

For example if a SW_TABLET_MODE switch is registered then GNOME will not
automatically show the onscreen keyboard when a text field gets focus on
touchscreen devices when SW_TABLET_MODE reports 0 and when SW_TABLET_MODE
reports 1 libinput will block (filter out) builtin keyboard and touchpad
events.

So to avoid unwanted side-effects EV_SW type inputs should only be
registered if they are actually present, only register SW_CAMERA_LENS_COVER
if it is actually there.

Fixes: 8af9fa37b8a3 ("platform/x86: dell-privacy: Add support for Dell hardware privacy")
Signed-off-by: Hans de Goede &lt;hdegoede@redhat.com&gt;
Link: https://lore.kernel.org/r/20221221220724.119594-2-hdegoede@redhat.com
</pre>
</div>
</content>
</entry>
<entry>
<title>platform/x86: dell-privacy: Fix SW_CAMERA_LENS_COVER reporting</title>
<updated>2023-01-12T18:40:19+00:00</updated>
<author>
<name>Hans de Goede</name>
<email>hdegoede@redhat.com</email>
</author>
<published>2022-12-21T22:07:23+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=1af7fef0d9d3fa075bf4e850f705df1fe97d33ce'/>
<id>1af7fef0d9d3fa075bf4e850f705df1fe97d33ce</id>
<content type='text'>
Use KE_VSW instead of KE_SW for the SW_CAMERA_LENS_COVER key_entry
and get the value of the switch from the status field when handling
SW_CAMERA_LENS_COVER events, instead of always reporting 0.

Also correctly set the initial SW_CAMERA_LENS_COVER value.

Fixes: 8af9fa37b8a3 ("platform/x86: dell-privacy: Add support for Dell hardware privacy")
Signed-off-by: Hans de Goede &lt;hdegoede@redhat.com&gt;
Link: https://lore.kernel.org/r/20221221220724.119594-1-hdegoede@redhat.com
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Use KE_VSW instead of KE_SW for the SW_CAMERA_LENS_COVER key_entry
and get the value of the switch from the status field when handling
SW_CAMERA_LENS_COVER events, instead of always reporting 0.

Also correctly set the initial SW_CAMERA_LENS_COVER value.

Fixes: 8af9fa37b8a3 ("platform/x86: dell-privacy: Add support for Dell hardware privacy")
Signed-off-by: Hans de Goede &lt;hdegoede@redhat.com&gt;
Link: https://lore.kernel.org/r/20221221220724.119594-1-hdegoede@redhat.com
</pre>
</div>
</content>
</entry>
<entry>
<title>platform/x86: asus-wmi: Don't load fan curves without fan</title>
<updated>2023-01-12T18:36:06+00:00</updated>
<author>
<name>Thomas Weißschuh</name>
<email>linux@weissschuh.net</email>
</author>
<published>2022-12-21T17:59:51+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=01fd7e7851ba2275662f771ee17d1f80e7bbfa52'/>
<id>01fd7e7851ba2275662f771ee17d1f80e7bbfa52</id>
<content type='text'>
If we do not have a fan it does not make sense to load curves for it.
This removes the following warnings from the kernel log:

asus_wmi: fan_curve_get_factory_default (0x00110024) failed: -19
asus_wmi: fan_curve_get_factory_default (0x00110025) failed: -19

Fixes: a2bdf10ce96e ("platform/x86: asus-wmi: Increase FAN_CURVE_BUF_LEN to 32")
Signed-off-by: Thomas Weißschuh &lt;linux@weissschuh.net&gt;
Link: https://lore.kernel.org/r/20221221-asus-fan-v1-3-e07f3949725b@weissschuh.net
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>
If we do not have a fan it does not make sense to load curves for it.
This removes the following warnings from the kernel log:

asus_wmi: fan_curve_get_factory_default (0x00110024) failed: -19
asus_wmi: fan_curve_get_factory_default (0x00110025) failed: -19

Fixes: a2bdf10ce96e ("platform/x86: asus-wmi: Increase FAN_CURVE_BUF_LEN to 32")
Signed-off-by: Thomas Weißschuh &lt;linux@weissschuh.net&gt;
Link: https://lore.kernel.org/r/20221221-asus-fan-v1-3-e07f3949725b@weissschuh.net
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/x86: asus-wmi: Ignore fan on E410MA</title>
<updated>2023-01-12T18:36:03+00:00</updated>
<author>
<name>Thomas Weißschuh</name>
<email>linux@weissschuh.net</email>
</author>
<published>2022-12-21T17:59:50+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=82cc5c6c624c63f7b57214e325e2ea685d924e89'/>
<id>82cc5c6c624c63f7b57214e325e2ea685d924e89</id>
<content type='text'>
The ASUS VivoBook has a fan device described in its ACPI tables but does
not actually contain any physical fan.
Use the quirk to inhibit fan handling.

Signed-off-by: Thomas Weißschuh &lt;linux@weissschuh.net&gt;
Link: https://lore.kernel.org/r/20221221-asus-fan-v1-2-e07f3949725b@weissschuh.net
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 ASUS VivoBook has a fan device described in its ACPI tables but does
not actually contain any physical fan.
Use the quirk to inhibit fan handling.

Signed-off-by: Thomas Weißschuh &lt;linux@weissschuh.net&gt;
Link: https://lore.kernel.org/r/20221221-asus-fan-v1-2-e07f3949725b@weissschuh.net
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>
</feed>
