linux-stable.git/drivers/platform, branch linux-5.18.y

platform/olpc: Fix uninitialized data in debugfs write

2022-08-17T12:41:54+00:00

[ Upstream commit 40ec787e1adf302c11668d4cc69838f4d584187d ]

The call to:

	size = simple_write_to_buffer(cmdbuf, sizeof(cmdbuf), ppos, buf, size);

will succeed if at least one byte is written to the "cmdbuf" buffer.
The "*ppos" value controls which byte is written.  Another problem is
that this code does not check for errors so it's possible for the entire
buffer to be uninitialized.

Inintialize the struct to zero to prevent reading uninitialized stack
data.

Debugfs is normally only writable by root so the impact of this bug is
very minimal.

Fixes: 6cca83d498bd ("Platform: OLPC: move debugfs support from x86 EC driver")
Signed-off-by: Dan Carpenter 
Link: https://lore.kernel.org/r/YthIKn+TfZSZMEcM@kili
Reviewed-by: Hans de Goede 
Signed-off-by: Hans de Goede 
Signed-off-by: Sasha Levin

platform/mellanox: mlxreg-lc: Fix error flow and extend verbosity

2022-08-17T12:41:54+00:00

[ Upstream commit b4b830a34d8046633231b7fe87f6f2cb6240dc9f ]

Fix error flow:
- Clean-up client object in case of probing failure.
- Prevent running remove routine in case of probing failure.
  Probing and removing are invoked by hotplug events raised upon line
  card insertion and removing. If probing procedure failed all data is
  cleared and there is nothing to do in remove routine.

Fixes: 62f9529b8d5c ("platform/mellanox: mlxreg-lc: Add initial support for Nvidia line card devices")
Signed-off-by: Vadim Pasternak 
Link: https://lore.kernel.org/r/20220719153540.61304-1-vadimp@nvidia.com
Reviewed-by: Hans de Goede 
Signed-off-by: Hans de Goede 
Signed-off-by: Sasha Levin

platform/x86: pmc_atom: Match all Lex BayTrail boards with critclk_systems DMI table

2022-08-17T12:41:54+00:00

[ Upstream commit c9d959fc32a5f9312282817052d8986614f2dc08 ]

The critclk_systems[] DMI match table already contains 2 Lex BayTrail
boards and patches were just submitted to add 3 more entries for the
following models: 3I380NX, 3I380A, 3I380CW.

Looking at: https://www.lex.com.tw/products/embedded-ipc-board/
we can see that Lex BayTrail makes many embedded boards with
multiple ethernet boards and none of their products are battery
powered so we don't need to worry (too much) about power consumption
when suspended.

Add a new DMI match which simply matches all Lex BayTrail boards and drop
the 2 existing board specific quirks.

Fixes: 648e921888ad ("clk: x86: Stop marking clocks as CLK_IS_CRITICAL")
Reported-by: Michael Schöne 
Reported-by: Paul Spooren 
Reported-by: Matwey V. Kornilov 
Signed-off-by: Hans de Goede 
Signed-off-by: Sasha Levin

platform/chrome: cros_ec: Always expose last resume result

2022-08-17T12:41:23+00:00

[ Upstream commit 74bb746407bf0d7c7d126c7731dbcd66d467619b ]

The last resume result exposing logic in cros_ec_sleep_event()
incorrectly requires S0ix support, which doesn't work on ARM based
systems where S0ix doesn't exist. That's because cros_ec_sleep_event()
only reports the last resume result when the EC indicates the last sleep
event was an S0ix resume. On ARM systems, the last sleep event is always
S3 resume, but the EC can still detect sleep hang events in case some
other part of the AP is blocking sleep.

Always expose the last resume result if the EC supports it so that this
works on all devices regardless of S0ix support. This fixes sleep hang
detection on ARM based chromebooks like Trogdor.

Cc: Rajat Jain 
Cc: Matthias Kaehlcke 
Cc: Hsin-Yi Wang 
Cc: Tzung-Bi Shih 
Reviewed-by: Guenter Roeck 
Reviewed-by: Evan Green 
Fixes: 7235560ac77a ("platform/chrome: Add support for v1 of host sleep event")
Signed-off-by: Stephen Boyd 
Signed-off-by: Tzung-Bi Shih 
Link: https://lore.kernel.org/r/20220614075726.2729987-1-swboyd@chromium.org
Signed-off-by: Sasha Levin

platform/x86: hp-wmi: Ignore Sanitization Mode event

2022-07-22T08:21:48+00:00

[ Upstream commit 9ab762a84b8094540c18a170e5ddd6488632c456 ]

After system resume the hp-wmi driver may complain:
[ 702.620180] hp_wmi: Unknown event_id - 23 - 0x0

According to HP it means 'Sanitization Mode' and it's harmless to just
ignore the event.

Cc: Jorge Lopez 
Signed-off-by: Kai-Heng Feng 
Link: https://lore.kernel.org/r/20220628123726.250062-1-kai.heng.feng@canonical.com
Reviewed-by: Hans de Goede 
Signed-off-by: Hans de Goede 
Signed-off-by: Sasha Levin

platform/x86: thinkpad_acpi: do not use PSC mode on Intel platforms

2022-07-22T08:21:48+00:00

[ Upstream commit bce6243f767f7da88aa4674d5d678f9f156eaba9 ]

PSC platform profile mode is only supported on Linux for AMD platforms.

Some older Intel platforms (e.g T490) are advertising it's capability
as Windows uses it - but on Linux we should only be using MMC profile
for Intel systems.

Add a check to prevent it being enabled incorrectly.

Signed-off-by: Mark Pearson 
Link: https://lore.kernel.org/r/20220627181449.3537-1-markpearson@lenovo.com
Reviewed-by: Hans de Goede 
Signed-off-by: Hans de Goede 
Signed-off-by: Sasha Levin

platform/x86: thinkpad-acpi: profile capabilities as integer

2022-07-22T08:21:48+00:00

[ Upstream commit 42504af775361ca2330a2bfde496a5ebc5655c86 ]

Currently the active mode (PSC/MMC) is stored in an enum and queried
throughout the driver.

Other driver changes will enumerate additional submodes that are relevant
to be tracked, so instead track PSC/MMC in a single integer variable.

Co-developed-by: Mario Limonciello 
Signed-off-by: Mario Limonciello 
Signed-off-by: Mark Pearson 
Link: https://lore.kernel.org/r/20220603170212.164963-1-markpearson@lenovo.com
Reviewed-by: Hans de Goede 
Signed-off-by: Hans de Goede 
Signed-off-by: Sasha Levin

platform/x86: intel/pmc: Add Alder Lake N support to PMC core driver

2022-07-22T08:21:47+00:00

[ Upstream commit d63eae6747eb8b3192e89712f6553c6aa162f872 ]

Add Alder Lake N (ADL-N) to the list of the platforms that Intel's
PMC core driver supports. Alder Lake N reuses all the TigerLake PCH IPs.

Cc: Srinivas Pandruvada 
Cc: Andy Shevchenko 
Cc: David E. Box 
Signed-off-by: Gayatri Kammela 
Reviewed-by: Rajneesh Bhardwaj 
Link: https://lore.kernel.org/r/20220615002751.3371730-1-gayatri.kammela@linux.intel.com
Reviewed-by: Hans de Goede 
Signed-off-by: Hans de Goede 
Signed-off-by: Sasha Levin

platform/x86: panasonic-laptop: filter out duplicate volume up/down/mute keypresses

2022-07-07T15:54:59+00:00

[ Upstream commit aacb455dfe01b7a24a792a2fbe7a04112ce8321d ]

On some Panasonic models the volume up/down/mute keypresses get
reported both through the Panasonic ACPI HKEY interface as well as
through the atkbd device.

Filter out the atkbd scan-codes for these to avoid reporting presses
twice.

Note normally we would leave the filtering of these to userspace by mapping
the scan-codes to KEY_UNKNOWN through /lib/udev/hwdb.d/60-keyboard.hwdb.
However in this case that would cause regressions since we were filtering
the Panasonic ACPI HKEY events before, so filter these in the kernel.

Fixes: ed83c9171829 ("platform/x86: panasonic-laptop: Resolve hotkey double trigger bug")
Reported-and-tested-by: Stefan Seyfried 
Reported-and-tested-by: Kenneth Chan 
Signed-off-by: Hans de Goede 
Reviewed-by: Andy Shevchenko 
Link: https://lore.kernel.org/r/20220624112340.10130-7-hdegoede@redhat.com
Signed-off-by: Sasha Levin

platform/x86: panasonic-laptop: don't report duplicate brightness key-presses

2022-07-07T15:54:59+00:00

[ Upstream commit 1f2c9de83a50447a2d7166f6273ab0c0e97cd68e ]

The brightness key-presses might also get reported by the ACPI video bus,
check for this and in this case don't report the presses to avoid reporting
2 presses for a single key-press.

Fixes: ed83c9171829 ("platform/x86: panasonic-laptop: Resolve hotkey double trigger bug")
Reported-and-tested-by: Stefan Seyfried 
Reported-and-tested-by: Kenneth Chan 
Signed-off-by: Hans de Goede 
Reviewed-by: Andy Shevchenko 
Link: https://lore.kernel.org/r/20220624112340.10130-6-hdegoede@redhat.com
Signed-off-by: Sasha Levin