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

platform/x86: intel_telemetry: Fix kernel doc descriptions

2023-12-20T16:00:23+00:00

[ Upstream commit a6584711e64d9d12ab79a450ec3628fd35e4f476 ]

LKP found issues with a kernel doc in the driver:

core.c:116: warning: Function parameter or member 'ioss_evtconfig' not described in 'telemetry_update_events'
core.c:188: warning: Function parameter or member 'ioss_evtconfig' not described in 'telemetry_get_eventconfig'

It looks like it were copy'n'paste typos when these descriptions
had been introduced. Fix the typos.

Reported-by: kernel test robot 
Closes: https://lore.kernel.org/oe-kbuild-all/202310070743.WALmRGSY-lkp@intel.com/
Signed-off-by: Andy Shevchenko 
Link: https://lore.kernel.org/r/20231120150756.1661425-1-andriy.shevchenko@linux.intel.com
Reviewed-by: Rajneesh Bhardwaj 
Reviewed-by: Ilpo Järvinen 
Signed-off-by: Ilpo Järvinen 
Signed-off-by: Sasha Levin

platform/surface: aggregator: fix recv_buf() return value

2023-12-13T17:39:20+00:00

commit c8820c92caf0770bec976b01fa9e82bb993c5865 upstream.

Serdev recv_buf() callback is supposed to return the amount of bytes
consumed, therefore an int in between 0 and count.

Do not return negative number in case of issue, when
ssam_controller_receive_buf() returns ESHUTDOWN just returns 0, e.g. no
bytes consumed, this keep the exact same behavior as it was before.

This fixes a potential WARN in serdev-ttyport.c:ttyport_receive_buf().

Fixes: c167b9c7e3d6 ("platform/surface: Add Surface Aggregator subsystem")
Cc: stable@vger.kernel.org
Signed-off-by: Francesco Dolcini 
Reviewed-by: Maximilian Luz 
Link: https://lore.kernel.org/r/20231128194935.11350-1-francesco@dolcini.it
Reviewed-by: Ilpo Järvinen 
Signed-off-by: Ilpo Järvinen 
Signed-off-by: Greg Kroah-Hartman

platform/mellanox: Check devm_hwmon_device_register_with_groups() return value

2023-12-13T17:39:07+00:00

[ Upstream commit 3494a594315b56516988afb6854d75dee5b501db ]

devm_hwmon_device_register_with_groups() returns an error pointer upon
failure. Check its return value for errors.

Compile-tested only.

Fixes: 1a218d312e65 ("platform/mellanox: mlxbf-pmc: Add Mellanox BlueField PMC driver")
Suggested-by: Ilpo Järvinen 
Suggested-by: Vadim Pasternak 
Signed-off-by: Kunwu Chan 
Reviewed-by: Vadim Pasternak 
Link: https://lore.kernel.org/r/20231201055447.2356001-1-chentao@kylinos.cn
[ij: split the change into two]
Reviewed-by: Ilpo Järvinen 
Signed-off-by: Ilpo Järvinen 
Signed-off-by: Sasha Levin

platform/mellanox: Add null pointer checks for devm_kasprintf()

2023-12-13T17:39:07+00:00

[ Upstream commit 2c7c857f5fed997be93047d2de853d7f10c8defe ]

devm_kasprintf() returns a pointer to dynamically allocated memory
which can be NULL upon failure.

Compile-tested only.

Fixes: 1a218d312e65 ("platform/mellanox: mlxbf-pmc: Add Mellanox BlueField PMC driver")
Suggested-by: Ilpo Järvinen 
Suggested-by: Vadim Pasternak 
Signed-off-by: Kunwu Chan 
Reviewed-by: Vadim Pasternak 
Link: https://lore.kernel.org/r/20231201055447.2356001-1-chentao@kylinos.cn
[ij: split the change into two]
Reviewed-by: Ilpo Järvinen 
Signed-off-by: Ilpo Järvinen 
Signed-off-by: Sasha Levin

mlxbf-bootctl: correctly identify secure boot with development keys

2023-12-13T17:39:07+00:00

[ Upstream commit d4eef75279f5e9d594f5785502038c763ce42268 ]

The secure boot state of the BlueField SoC is represented by two bits:
                0 = production state
                1 = secure boot enabled
                2 = non-secure (secure boot disabled)
                3 = RMA state
There is also a single bit to indicate whether production keys or
development keys are being used when secure boot is enabled.
This single bit (specified by MLXBF_BOOTCTL_SB_DEV_MASK) only has
meaning if secure boot state equals 1 (secure boot enabled).

The secure boot states are as follows:
- “GA secured” is when secure boot is enabled with official production keys.
- “Secured (development)” is when secure boot is enabled with development keys.

Without this fix “GA Secured” is displayed on development cards which is
misleading. This patch updates the logic in "lifecycle_state_show()" to
handle the case where the SoC is configured for secure boot and is using
development keys.

Fixes: 79e29cb8fbc5c ("platform/mellanox: Add bootctl driver for Mellanox BlueField Soc")
Reviewed-by: Khalil Blaiech 
Signed-off-by: David Thompson 
Link: https://lore.kernel.org/r/20231130183515.17214-1-davthompson@nvidia.com
Reviewed-by: Ilpo Järvinen 
Signed-off-by: Ilpo Järvinen 
Signed-off-by: Sasha Levin

platform/x86: wmi: Skip blocks with zero instances

2023-12-13T17:39:06+00:00

[ Upstream commit cbf54f37600e874d82886aa3b2f471778cae01ce ]

Some machines like the HP Omen 17 ck2000nf contain WMI blocks
with zero instances, so any WMI driver which tries to handle the
associated WMI device will fail.
Skip such WMI blocks to avoid confusing any WMI drivers.

Reported-by: Alexis Belmonte 
Closes: https://bugzilla.kernel.org/show_bug.cgi?id=218188
Fixes: bff431e49ff5 ("ACPI: WMI: Add ACPI-WMI mapping driver")
Tested-by: Alexis Belmonte 
Signed-off-by: Armin Wolf 
Link: https://lore.kernel.org/r/20231129181654.5800-1-W_Armin@gmx.de
Reviewed-by: Ilpo Järvinen 
Signed-off-by: Ilpo Järvinen 
Signed-off-by: Sasha Levin

platform/x86: asus-wmi: Move i8042 filter install to shared asus-wmi code

2023-12-13T17:39:05+00:00

[ Upstream commit b52cbca22cbf6c9d2700c1e576d0ddcc670e49d5 ]

asus-nb-wmi calls i8042_install_filter() in some cases, but it never
calls i8042_remove_filter(). This means that a dangling pointer to
the filter function is left after rmmod leading to crashes.

Fix this by moving the i8042-filter installation to the shared
asus-wmi code and also remove it from the shared code on driver unbind.

Fixes: b5643539b825 ("platform/x86: asus-wmi: Filter buggy scan codes on ASUS Q500A")
Cc: Oleksij Rempel 
Signed-off-by: Hans de Goede 
Link: https://lore.kernel.org/r/20231120154235.610808-2-hdegoede@redhat.com
Reviewed-by: Ilpo Järvinen 
Signed-off-by: Ilpo Järvinen 
Signed-off-by: Sasha Levin

platform/x86: thinkpad_acpi: Add battery quirk for Thinkpad X120e

2023-11-28T17:06:56+00:00

[ Upstream commit 916646758aea81a143ce89103910f715ed923346 ]

Thinkpad X120e also needs this battery quirk.

Signed-off-by: Olli Asikainen 
Link: https://lore.kernel.org/r/20231024190922.2742-1-olli.asikainen@gmail.com
Reviewed-by: Ilpo Järvinen 
Signed-off-by: Ilpo Järvinen 
Signed-off-by: Sasha Levin

platform/chrome: kunit: initialize lock for fake ec_dev

2023-11-28T17:06:56+00:00

[ Upstream commit e410b4ade83d06a046f6e32b5085997502ba0559 ]

cros_ec_cmd_xfer() uses ec_dev->lock.  Initialize it.

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

Reviewed-by: Guenter Roeck 
Link: https://lore.kernel.org/r/20231003080504.4011337-1-tzungbi@kernel.org
Signed-off-by: Tzung-Bi Shih 
Signed-off-by: Sasha Levin

platform/x86: wmi: Fix opening of char device

2023-11-20T10:51:57+00:00

[ Upstream commit eba9ac7abab91c8f6d351460239108bef5e7a0b6 ]

Since commit fa1f68db6ca7 ("drivers: misc: pass miscdevice pointer via
file private data"), the miscdevice stores a pointer to itself inside
filp->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 
Link: https://lore.kernel.org/r/20231020211005.38216-5-W_Armin@gmx.de
Reviewed-by: Ilpo Järvinen 
Signed-off-by: Ilpo Järvinen 
Signed-off-by: Sasha Levin