linux-stable.git/drivers/platform, branch v6.10.8

platform/x86: ISST: Fix return value on last invalid resource

2024-08-29T15:36:07+00:00

commit 46ee21e9f59205e54943dfe51b2dc8a9352ca37d upstream.

When only the last resource is invalid, tpmi_sst_dev_add() is returing
error even if there are other valid resources before. This function
should return error when there are no valid resources.

Here tpmi_sst_dev_add() is returning "ret" variable. But this "ret"
variable contains the failure status of last call to sst_main(), which
failed for the invalid resource. But there may be other valid resources
before the last entry.

To address this, do not update "ret" variable for sst_main() return
status.

If there are no valid resources, it is already checked for by !inst
below the loop and -ENODEV is returned.

Fixes: 9d1d36268f3d ("platform/x86: ISST: Support partitioned systems")
Signed-off-by: Srinivas Pandruvada 
Cc: stable@vger.kernel.org # 6.10+
Link: https://lore.kernel.org/r/20240816163626.415762-1-srinivas.pandruvada@linux.intel.com
Reviewed-by: Ilpo Järvinen 
Signed-off-by: Ilpo Järvinen 
Signed-off-by: Greg Kroah-Hartman

platform/x86: dell-uart-backlight: Use acpi_video_get_backlight_type()

2024-08-29T15:36:07+00:00

commit b5f0943001339c4d324a1af10470ce0bdd79f966 upstream.

The dell-uart-backlight driver supports backlight control on Dell All In
One (AIO) models using a backlight controller board connected to an UART.

In DSDT this uart port will be defined as:

   Name (_HID, "DELL0501")
   Name (_CID, EisaId ("PNP0501")

Now the first AIO has turned up which has not only the DSDT bits for this,
but also an actual controller attached to the UART, yet it is not using
this controller for backlight control.

Use the acpi_video_get_backlight_type() function from the ACPI video-detect
code to check if the dell-uart-backlight driver should actually be used.
This allows reusing the existing ACPI video-detect infra to override
the backlight control method on the commandline or with DMI quirks.

Fixes: 484bae9e4d6a ("platform/x86: Add new Dell UART backlight driver")
Cc: All applicable 
Signed-off-by: Hans de Goede 
Reviewed-by: Andy Shevchenko 
Link: https://patch.msgid.link/20240814190159.15650-3-hdegoede@redhat.com
Signed-off-by: Rafael J. Wysocki 
Signed-off-by: Greg Kroah-Hartman

platform/surface: aggregator: Fix warning when controller is destroyed in probe

2024-08-29T15:35:55+00:00

[ Upstream commit bc923d594db21bee0ead128eb4bb78f7e77467a4 ]

There is a small window in ssam_serial_hub_probe() where the controller
is initialized but has not been started yet. Specifically, between
ssam_controller_init() and ssam_controller_start(). Any failure in this
window, for example caused by a failure of serdev_device_open(),
currently results in an incorrect warning being emitted.

In particular, any failure in this window results in the controller
being destroyed via ssam_controller_destroy(). This function checks the
state of the controller and, in an attempt to validate that the
controller has been cleanly shut down before we try and deallocate any
resources, emits a warning if that state is not SSAM_CONTROLLER_STOPPED.

However, since we have only just initialized the controller and have not
yet started it, its state is SSAM_CONTROLLER_INITIALIZED. Note that this
is the only point at which the controller has this state, as it will
change after we start the controller with ssam_controller_start() and
never revert back. Further, at this point no communication has taken
place and the sender and receiver threads have not been started yet (and
we may not even have an open serdev device either).

Therefore, it is perfectly safe to call ssam_controller_destroy() with a
state of SSAM_CONTROLLER_INITIALIZED. This, however, means that the
warning currently being emitted is incorrect. Fix it by extending the
check.

Fixes: c167b9c7e3d6 ("platform/surface: Add Surface Aggregator subsystem")
Signed-off-by: Maximilian Luz 
Link: https://lore.kernel.org/r/20240811124645.246016-1-luzmaximilian@gmail.com
Reviewed-by: Ilpo Järvinen 
Signed-off-by: Ilpo Järvinen 
Signed-off-by: Sasha Levin

platform/x86: ideapad-laptop: add a mutex to synchronize VPC commands

2024-08-19T04:05:39+00:00

[ Upstream commit 7cc06e729460a209b84d3db4db56c9f85f048cc2 ]

Calling VPC commands consists of several VPCW and VPCR ACPI calls.
These calls and their results can get mixed up if they are called
simultaneously from different threads, like acpi notify handler,
sysfs, debugfs, notification chain.

The commit e2ffcda16290 ("ACPI: OSL: Allow Notify () handlers to run on
all CPUs") made the race issues much worse than before it but some
races were possible even before that commit.

Add a mutex to synchronize VPC commands.

Fixes: e2ffcda16290 ("ACPI: OSL: Allow Notify () handlers to run on all CPUs")
Fixes: e82882cdd241 ("platform/x86: Add driver for Yoga Tablet Mode switch")
Signed-off-by: Gergo Koteles 
Link: https://lore.kernel.org/r/f26782fa1194ad11ed5d9ba121a804e59b58b026.1721898747.git.soyer@irl.hu
Reviewed-by: Ilpo Järvinen 
Signed-off-by: Ilpo Järvinen 
Signed-off-by: Sasha Levin

platform/x86: ideapad-laptop: move ymc_trigger_ec from lenovo-ymc

2024-08-19T04:05:39+00:00

[ Upstream commit cde7886b35176d56e72bfc68dc104fa08e7b072c ]

Some models need to trigger the EC after each YMC event for the yoga
mode control to work properly. EC triggering consist of a VPC call from
the lenovo-ymc module. Except for this, all VPC calls are in the
ideapad-laptop module.

Since ideapad-laptop has a notification chain, a new YMC_EVENT action
can be added and triggered from the lenovo-ymc module. Then the
ideapad-laptop can trigger the EC.

If the triggering is in the ideapad-laptop module, then the ec_trigger
module parameter should be there as well.

Move the ymc_trigger_ec functionality and the ec_trigger module
parameter to the ideapad-laptop module.

Signed-off-by: Gergo Koteles 
Reviewed-by: Ilpo Järvinen 
Link: https://lore.kernel.org/r/d980ab3ac32b5e554f456b0ff17279bfdbe2a203.1721898747.git.soyer@irl.hu
Signed-off-by: Ilpo Järvinen 
Stable-dep-of: 7cc06e729460 ("platform/x86: ideapad-laptop: add a mutex to synchronize VPC commands")
Signed-off-by: Sasha Levin

platform/x86: ideapad-laptop: introduce a generic notification chain

2024-08-19T04:05:39+00:00

[ Upstream commit 613e3900c24bb1379d994f44d75d31c3223cc263 ]

There are several cases where a notification chain can simplify Lenovo
WMI drivers.

Add a generic notification chain into ideapad-laptop.

Signed-off-by: Gergo Koteles 
Link: https://lore.kernel.org/r/c5a43efae8a32bd034c3d19c0a686941347575a7.1721898747.git.soyer@irl.hu
Reviewed-by: Ilpo Järvinen 
Signed-off-by: Ilpo Järvinen 
Stable-dep-of: 7cc06e729460 ("platform/x86: ideapad-laptop: add a mutex to synchronize VPC commands")
Signed-off-by: Sasha Levin

platform/x86/amd/pmf: Fix to Update HPD Data When ALS is Disabled

2024-08-19T04:05:39+00:00

[ Upstream commit 78296429e20052b029211b0aca64aadc5052d581 ]

If the Ambient Light Sensor (ALS) is disabled, the current code in the PMF
driver does not query for Human Presence Detection (HPD) data in
amd_pmf_get_sensor_info(). As a result, stale HPD data is used by PMF-TA
to evaluate policy conditions, leading to unexpected behavior in the policy
output actions.

To resolve this issue, modify the PMF driver to query HPD data
independently of ALS.

Since user_present is a boolean, modify the current code to return true if
the user is present and false if the user is away or if the sensor is not
detected, and report this status to the PMF TA firmware accordingly.

With this change, amd_pmf_get_sensor_info() now returns void instead of
int.

Fixes: cedecdba60f4 ("platform/x86/amd/pmf: Get ambient light information from AMD SFH driver")
Co-developed-by: Patil Rajesh Reddy 
Signed-off-by: Patil Rajesh Reddy 
Signed-off-by: Shyam Sundar S K 
Link: https://lore.kernel.org/r/20240730142316.3846259-1-Shyam-sundar.S-k@amd.com
Reviewed-by: Ilpo Järvinen 
Signed-off-by: Ilpo Järvinen 
Signed-off-by: Sasha Levin

platform/chrome: cros_ec_lpc: Add a new quirk for ACPI id

2024-08-14T13:34:05+00:00

[ Upstream commit 040159e0912c31fe959d8671f9700bda105ab63a ]

Framework Laptops' ACPI exposes the EC with id "PNP0C09". But
"PNP0C09" is part of the ACPI standard; there are lots of computers
with EC chips with this id, and most of them don't support the cros_ec
protocol.

The driver could find the ACPI device by having "PNP0C09" in the
acpi_match_table, but this would match devices which don't support the
cros_ec protocol. Instead, add a new quirk "CROS_EC_LPC_QUIRK_ACPI_ID"
which allows the id to be specified. This quirk is applied after the
DMI check shows that the device is supported.

Tested-by: Dustin L. Howett 
Signed-off-by: Ben Walsh 
Link: https://lore.kernel.org/r/20240605063351.14836-4-ben@jubnut.com
Signed-off-by: Tzung-Bi Shih 
Signed-off-by: Sasha Levin

platform/x86/intel/ifs: Initialize union ifs_status to zero

2024-08-14T13:34:00+00:00

[ Upstream commit 3114f77e9453daa292ec0906f313a715c69b5943 ]

If the IFS scan test exits prematurely due to a timeout before
completing a single run, the union ifs_status remains uninitialized,
leading to incorrect test status reporting. To prevent this, always
initialize the union ifs_status to zero.

Fixes: 2b40e654b73a ("platform/x86/intel/ifs: Add scan test support")
Suggested-by: Ilpo Järvinen 
Reviewed-by: Jithu Joseph 
Reviewed-by: Ashok Raj 
Signed-off-by: Kuppuswamy Sathyanarayanan 
Link: https://lore.kernel.org/r/20240730155930.1754744-1-sathyanarayanan.kuppuswamy@linux.intel.com
Reviewed-by: Ilpo Järvinen 
Signed-off-by: Ilpo Järvinen 
Signed-off-by: Sasha Levin

platform/x86: intel-vbtn: Protect ACPI notify handler against recursion

2024-08-14T13:34:00+00:00

[ Upstream commit e075c3b13a0a142dcd3151b25d29a24f31b7b640 ]

Since commit e2ffcda16290 ("ACPI: OSL: Allow Notify () handlers to run on
all CPUs") ACPI notify handlers like the intel-vbtn notify_handler() may
run on multiple CPU cores racing with themselves.

This race gets hit on Dell Venue 7140 tablets when undocking from
the keyboard, causing the handler to try and register priv->switches_dev
twice, as can be seen from the dev_info() message getting logged twice:

[ 83.861800] intel-vbtn INT33D6:00: Registering Intel Virtual Switches input-dev after receiving a switch event
[ 83.861858] input: Intel Virtual Switches as /devices/pci0000:00/0000:00:1f.0/PNP0C09:00/INT33D6:00/input/input17
[ 83.861865] intel-vbtn INT33D6:00: Registering Intel Virtual Switches input-dev after receiving a switch event

After which things go seriously wrong:
[ 83.861872] sysfs: cannot create duplicate filename '/devices/pci0000:00/0000:00:1f.0/PNP0C09:00/INT33D6:00/input/input17'
...
[ 83.861967] kobject: kobject_add_internal failed for input17 with -EEXIST, don't try to register things with the same name in the same directory.
[ 83.877338] BUG: kernel NULL pointer dereference, address: 0000000000000018
...

Protect intel-vbtn notify_handler() from racing with itself with a mutex
to fix this.

Fixes: e2ffcda16290 ("ACPI: OSL: Allow Notify () handlers to run on all CPUs")
Reported-by: En-Wei Wu 
Closes: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2073001
Tested-by: Kostadin Stoilov 
Signed-off-by: Hans de Goede 
Link: https://lore.kernel.org/r/20240729120443.14779-1-hdegoede@redhat.com
Reviewed-by: Ilpo Järvinen 
Signed-off-by: Ilpo Järvinen 
Signed-off-by: Sasha Levin