linux-stable.git/drivers/platform, branch v5.18.4

platform/x86: hp-wmi: Use zero insize parameter only when supported

2022-06-14T16:45:16+00:00

[ Upstream commit 65f936f3535950d2643eac5bf34a735a0e428cdd ]

commit be9d73e64957 ("platform/x86: hp-wmi: Fix 0x05 error code reported by
several WMI calls") and commit 12b19f14a21a ("platform/x86: hp-wmi: Fix
hp_wmi_read_int() reporting error (0x05)") cause ACPI BIOS Error (bug):
Attempt to CreateField of length zero (20211217/dsopcode-133) because of
the ACPI method HWMC, which unconditionally creates a Field of
size (insize*8) bits:
	CreateField (Arg1, 0x80, (Local5 * 0x08), DAIN)
In cases where args->insize = 0, the Field size is 0, resulting in
an error.

Fix this by using zero insize only if 0x5 error code is returned

Tested on Omen 15 AMD (2020) board ID: 8786.

Fixes: be9d73e64957 ("platform/x86: hp-wmi: Fix 0x05 error code reported by several WMI calls")
Signed-off-by: Bedant Patnaik 
Tested-by: Jorge Lopez 
Link: https://lore.kernel.org/r/41be46743d21c78741232a47bbb5f1cdbcc3d21e.camel@gmail.com
Reviewed-by: Hans de Goede 
Signed-off-by: Hans de Goede 
Signed-off-by: Sasha Levin

platform/x86: hp-wmi: Resolve WMI query failures on some devices

2022-06-14T16:45:15+00:00

[ Upstream commit dc6a6ab58379f25bf991d8e4a13b001ed806e881 ]

WMI queries fail on some devices where the ACPI method HWMC
unconditionally attempts to create Fields beyond the buffer
if the buffer is too small, this breaks essential features
such as power profiles:

         CreateByteField (Arg1, 0x10, D008)
         CreateByteField (Arg1, 0x11, D009)
         CreateByteField (Arg1, 0x12, D010)
         CreateDWordField (Arg1, 0x10, D032)
         CreateField (Arg1, 0x80, 0x0400, D128)

In cases where args->data had zero length, ACPI BIOS Error
(bug): AE_AML_BUFFER_LIMIT, Field [D008] at bit
offset/length 128/8 exceeds size of target Buffer (128 bits)
(20211217/dsopcode-198) was obtained.

ACPI BIOS Error (bug): AE_AML_BUFFER_LIMIT, Field [D009] at bit
offset/length 136/8 exceeds size of target Buffer (136bits)
(20211217/dsopcode-198)

The original code created a buffer size of 128 bytes regardless if
the WMI call required a smaller buffer or not.  This particular
behavior occurs in older BIOS and reproduced in OMEN laptops.  Newer
BIOS handles buffer sizes properly and meets the latest specification
requirements.  This is the reason why testing with a dynamically
allocated buffer did not uncover any failures with the test systems at
hand.

This patch was tested on several OMEN, Elite, and Zbooks.  It was
confirmed the patch resolves HPWMI_FAN GET/SET calls in an OMEN
Laptop 15-ek0xxx.  No problems were reported when testing on several Elite
and Zbooks notebooks.

Fixes: 4b4967cbd268 ("platform/x86: hp-wmi: Changing bios_args.data to be dynamically allocated")
Signed-off-by: Jorge Lopez 
Reviewed-by: Andy Shevchenko 
Link: https://lore.kernel.org/r/20220608212923.8585-2-jorge.lopez2@hp.com
Reviewed-by: Hans de Goede 
Signed-off-by: Hans de Goede 
Signed-off-by: Sasha Levin

platform/x86: barco-p50-gpio: Add check for platform_driver_register

2022-06-14T16:45:15+00:00

[ Upstream commit 011881b80ebe773914b59905bce0f5e0ef93e7ba ]

As platform_driver_register() could fail, it should be better
to deal with the return value in order to maintain the code
consisitency.

Fixes: 86af1d02d458 ("platform/x86: Support for EC-connected GPIOs for identify LED/button on Barco P50 board")
Signed-off-by: Jiasheng Jiang 
Acked-by: Peter Korsgaard 
Link: https://lore.kernel.org/r/20220526090345.1444172-1-jiasheng@iscas.ac.cn
Signed-off-by: Hans de Goede 
Signed-off-by: Sasha Levin

MIPS: Loongson: Use hwmon_device_register_with_groups() to register hwmon

2022-06-09T08:30:35+00:00

[ Upstream commit abae018a03821be2b65c01ebe2bef06fd7d85a4c ]

Calling hwmon_device_register_with_info() with NULL dev and/or chip
information parameters is an ABI abuse and not a real conversion to
the new API. Also, the code creates sysfs attributes _after_ creating
the hwmon device, which is racy and unsupported to start with. On top
of that, the removal code tries to remove the name attribute which is
owned by the hwmon core.

Use hwmon_device_register_with_groups() to register the hwmon device
instead.

In the future, the hwmon subsystem will reject calls to
hwmon_device_register_with_info with NULL dev or chip/info parameters.
Without this patch, the hwmon device will fail to register.

Fixes: f59dc5119192 ("MIPS: Loongson: Fix boot warning about hwmon_device_register()")
Cc: Zhi Li 
Signed-off-by: Guenter Roeck 
Signed-off-by: Thomas Bogendoerfer 
Signed-off-by: Sasha Levin

platform/chrome: Re-introduce cros_ec_cmd_xfer and use it for ioctls

2022-06-09T08:30:24+00:00

[ Upstream commit 57b888ca2541785de2fcb90575b378921919b6c0 ]

Commit 413dda8f2c6f ("platform/chrome: cros_ec_chardev: Use
cros_ec_cmd_xfer_status helper") inadvertendly changed the userspace ABI.
Previously, cros_ec ioctls would only report errors if the EC communication
failed, and otherwise return success and the result of the EC
communication. An EC command execution failure was reported in the EC
response field. The above mentioned commit changed this behavior, and the
ioctl itself would fail. This breaks userspace commands trying to analyze
the EC command execution error since the actual EC command response is no
longer reported to userspace.

Fix the problem by re-introducing the cros_ec_cmd_xfer() helper, and use it
to handle ioctl messages.

Fixes: 413dda8f2c6f ("platform/chrome: cros_ec_chardev: Use cros_ec_cmd_xfer_status helper")
Cc: Daisuke Nojiri 
Cc: Rob Barnes 
Cc: Rajat Jain 
Cc: Brian Norris 
Cc: Parth Malkan 
Reviewed-by: Daisuke Nojiri 
Reviewed-by: Brian Norris 
Signed-off-by: Guenter Roeck 
Signed-off-by: Tzung-Bi Shih 
Signed-off-by: Sasha Levin

platform/chrome: cros_ec: fix error handling in cros_ec_register()

2022-06-09T08:30:24+00:00

[ Upstream commit 2cd01bd6b117df07b1bc2852f08694fdd29e40ed ]

Fix cros_ec_register() to unregister platform devices if
blocking_notifier_chain_register() fails.

Also use the single exit path to handle the platform device
unregistration.

Fixes: 42cd0ab476e2 ("platform/chrome: cros_ec: Query EC protocol version if EC transitions between RO/RW")
Reviewed-by: Prashant Malani 
Signed-off-by: Tzung-Bi Shih 
Signed-off-by: Sasha Levin

platform/x86: intel_cht_int33fe: Set driver data

2022-06-09T08:30:18+00:00

[ Upstream commit 3ce827bf9cfecaf2cbfd9a9d44f0db9f40882780 ]

Module removal fails because cht_int33fe_typec_remove()
tries to access driver data that does not exist. Fixing by
assigning the data at the end of probe.

Fixes: 915623a80b5a ("platform/x86: intel_cht_int33fe: Switch to DMI modalias based loading")
Signed-off-by: Heikki Krogerus 
Link: https://lore.kernel.org/r/20220519122103.78546-1-heikki.krogerus@linux.intel.com
Reviewed-by: Hans de Goede 
Signed-off-by: Hans de Goede 
Signed-off-by: Sasha Levin

platform/x86: intel-hid: fix _DSM function index handling

2022-06-09T08:29:29+00:00

commit 1620c80bba53af8c547bab34a1d3bc58319fe608 upstream.

intel_hid_dsm_fn_mask is a bit mask containing one bit for each function
index. Fix the function index check in intel_hid_evaluate_method
accordingly, which was missed in commit 97ab4516205e ("platform/x86:
intel-hid: fix _DSM function index handling").

Fixes: 97ab4516205e ("platform/x86: intel-hid: fix _DSM function index handling")
Cc: stable@vger.kernel.org
Signed-off-by: Michael Niewöhner 
Link: https://lore.kernel.org/r/66f813f5bcc724a0f6dd5adefe6a9728dbe509e3.camel@mniewoehner.de
Reviewed-by: Hans de Goede 
Signed-off-by: Hans de Goede 
Signed-off-by: Greg Kroah-Hartman

platform/surface: aggregator: Fix initialization order when compiling as builtin module

2022-05-06T11:05:57+00:00

When building the Surface Aggregator Module (SAM) core, registry, and
other SAM client drivers as builtin modules (=y), proper initialization
order is not guaranteed. Due to this, client driver registration
(triggered by device registration in the registry) races against bus
initialization in the core.

If any attempt is made at registering the device driver before the bus
has been initialized (i.e. if bus initialization fails this race) driver
registration will fail with a message similar to:

    Driver surface_battery was unable to register with bus_type surface_aggregator because the bus was not initialized

Switch from module_init() to subsys_initcall() to resolve this issue.
Note that the serdev subsystem uses postcore_initcall() so we are still
able to safely register the serdev device driver for the core.

Fixes: c167b9c7e3d6 ("platform/surface: Add Surface Aggregator subsystem")
Reported-by: Blaž Hrastnik 
Signed-off-by: Maximilian Luz 
Link: https://lore.kernel.org/r/20220429195738.535751-1-luzmaximilian@gmail.com
Reviewed-by: Hans de Goede 
Signed-off-by: Hans de Goede

platform/surface: gpe: Add support for Surface Pro 8

2022-05-06T11:05:57+00:00

The new Surface Pro 8 uses GPEs for lid events as well. Add an entry for
that so that the lid can be used to wake the device. Note that this is a
device with a keyboard type-cover, where this acts as the "lid".

Signed-off-by: Maximilian Luz 
Link: https://lore.kernel.org/r/20220429180049.1282447-1-luzmaximilian@gmail.com
Signed-off-by: Hans de Goede