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

platform/chrome: cros_ec_proto: Send command again when timeout occurs

2021-09-18T11:44:03+00:00

commit 3abc16af57c9939724df92fcbda296b25cc95168 upstream.

Sometimes kernel is trying to probe Fingerprint MCU (FPMCU) when it
hasn't initialized SPI yet. This can happen because FPMCU is restarted
during system boot and kernel can send message in short window
eg. between sysjump to RW and SPI initialization.

Cc:  # 4.4+
Signed-off-by: Patryk Duda 
Link: https://lore.kernel.org/r/20210518140758.29318-1-pdk@semihalf.com
Signed-off-by: Benson Leung 
Signed-off-by: Greg Kroah-Hartman

platform/x86: dell-smbios-wmi: Add missing kfree in error-exit from run_smbios_call

2021-09-18T11:43:33+00:00

[ Upstream commit 0487d4fc42d7f31a56cfd9e2237f9ebd889e6112 ]

As pointed out be Kees Cook if we return -EIO because the
obj->type != ACPI_TYPE_BUFFER, then we must kfree the
output buffer before the return.

Fixes: 1a258e670434 ("platform/x86: dell-smbios-wmi: Add new WMI dispatcher driver")
Reported-by: Kees Cook 
Signed-off-by: Hans de Goede 
Link: https://lore.kernel.org/r/20210826140822.71198-1-hdegoede@redhat.com
Signed-off-by: Sasha Levin

platform/x86: ISST: Fix optimization with use of numa

2021-09-18T11:43:30+00:00

[ Upstream commit d36d4a1d75d2a8bd14ec00d5cb0ce166f6886146 ]

When numa is used to map CPU to PCI device, the optimized path to read
from cached data is not working and still calls _isst_if_get_pci_dev().

The reason is that when caching the mapping, numa information is not
available as it is read later. So move the assignment of
isst_cpu_info[cpu].numa_node before calling _isst_if_get_pci_dev().

Fixes: aa2ddd242572 ("platform/x86: ISST: Use numa node id for cpu pci dev mapping")
Signed-off-by: Srinivas Pandruvada 
Link: https://lore.kernel.org/r/20210727165052.427238-1-srinivas.pandruvada@linux.intel.com
Signed-off-by: Hans de Goede 
Signed-off-by: Sasha Levin

platform/x86: gigabyte-wmi: add support for B450M S2H V2

2021-08-18T17:39:31+00:00

Reported as working here:
https://github.com/t-8ch/linux-gigabyte-wmi-driver/issues/1#issuecomment-901207693

Signed-off-by: Thomas Weißschuh 
Link: https://lore.kernel.org/r/20210818164435.99821-1-linux@weissschuh.net
Signed-off-by: Hans de Goede

platform/x86: gigabyte-wmi: add support for X570 GAMING X

2021-08-18T07:43:51+00:00

Reported as working here:
https://github.com/t-8ch/linux-gigabyte-wmi-driver/issues/1#issuecomment-900263115

Signed-off-by: Thomas Weißschuh 
Link: https://lore.kernel.org/r/20210817154628.84992-1-linux@weissschuh.net
Signed-off-by: Hans de Goede

platform/x86: asus-nb-wmi: Add tablet_mode_sw=lid-flip quirk for the TP200s

2021-08-12T15:18:28+00:00

The Asus TP200s / E205SA 360 degree hinges 2-in-1 supports reporting
SW_TABLET_MODE info through the ASUS_WMI_DEVID_LID_FLIP WMI device-id.
Add a quirk to enable this.

BugLink: https://gitlab.freedesktop.org/libinput/libinput/-/issues/639
Signed-off-by: Hans de Goede 
Link: https://lore.kernel.org/r/20210812145513.39117-2-hdegoede@redhat.com

platform/x86: asus-nb-wmi: Allow configuring SW_TABLET_MODE method with a module option

2021-08-12T15:18:19+00:00

Unfortunately we have been unable to find a reliable way to detect if
and how SW_TABLET_MODE reporting is supported, so we are relying on
DMI quirks for this.

Add a module-option to specify the SW_TABLET_MODE method so that this can
be easily tested without needing to rebuild the kernel.

BugLink: https://gitlab.freedesktop.org/libinput/libinput/-/issues/639
Signed-off-by: Hans de Goede 
Link: https://lore.kernel.org/r/20210812145513.39117-1-hdegoede@redhat.com

platform/x86: pcengines-apuv2: Add missing terminating entries to gpio-lookup tables

2021-08-06T12:04:43+00:00

The gpiod_lookup_table.table passed to gpiod_add_lookup_table() must
be terminated with an empty entry, add this.

Note we have likely been getting away with this not being present because
the GPIO lookup code first matches on the dev_id, causing most lookups to
skip checking the table and the lookups which do check the table will
find a matching entry before reaching the end. With that said, terminating
these tables properly still is obviously the correct thing to do.

Fixes: f8eb0235f659 ("x86: pcengines apuv2 gpio/leds/keys platform driver")
Signed-off-by: Hans de Goede 
Link: https://lore.kernel.org/r/20210806115515.12184-1-hdegoede@redhat.com

platform/x86: Make dual_accel_detect() KIOX010A + KIOX020A detect more robust

2021-08-06T12:04:43+00:00

360 degree hinges devices with dual KIOX010A + KIOX020A accelerometers
always have both a KIOX010A and a KIOX020A ACPI device (one for each
accel).

Theoretical some vendor may re-use some DSDT for a non-convertible
stripping out just the KIOX020A ACPI device from the DSDT. Check that
both ACPI devices are present to make the check more robust.

Fixes: 153cca9caa81 ("platform/x86: Add and use a dual_accel_detect() helper")
Signed-off-by: Hans de Goede 
Link: https://lore.kernel.org/r/20210802141000.978035-1-hdegoede@redhat.com

platform/x86: Add and use a dual_accel_detect() helper

2021-07-29T11:14:07+00:00

Various 360 degree hinges (yoga) style 2-in-1 devices use 2 accelerometers
to allow the OS to determine the angle between the display and the base of
the device.

On Windows these are read by a special HingeAngleService process which
calls undocumented ACPI methods, to let the firmware know if the 2-in-1 is
in tablet- or laptop-mode. The firmware may use this to disable the kbd and
touchpad to avoid spurious input in tablet-mode as well as to report
SW_TABLET_MODE info to the OS.

Since Linux does not call these undocumented methods, the SW_TABLET_MODE
info reported by various pdx86 drivers is incorrect on these devices.

Before this commit the intel-hid and thinkpad_acpi code already had 2
hardcoded checks for ACPI hardware-ids of dual-accel sensors to avoid
reporting broken info.

And now we also have a bug-report about the same problem in the intel-vbtn
code. Since there are at least 3 different ACPI hardware-ids in play, add
a new dual_accel_detect() helper which checks for all 3, rather then
adding different hardware-ids to the drivers as bug-reports trickle in.
Having shared code which checks all known hardware-ids is esp. important
for the intel-hid and intel-vbtn drivers as these are generic drivers
which are used on a lot of devices.

The BOSC0200 hardware-id requires special handling, because often it is
used for a single-accelerometer setup. Only in a few cases it refers to
a dual-accel setup, in which case there will be 2 I2cSerialBus resources
in the device's resource-list, so the helper checks for this.

BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=209011
Reported-and-tested-by: Julius Lehmann 
Signed-off-by: Hans de Goede 
Reviewed-by: Andy Shevchenko 
Link: https://lore.kernel.org/r/20210729082134.6683-1-hdegoede@redhat.com