user/sven/linux.git/drivers/platform, branch v6.1.21

platform: x86: MLX_PLATFORM: select REGMAP instead of depending on it

2023-03-17T07:50:27Z

[ Upstream commit 7e7e1541c91615e9950d0b96bcd1806d297e970e ] REGMAP is a hidden (not user visible) symbol. Users cannot set it directly thru "make *config", so drivers should select it instead of depending on it if they need it. Consistently using "select" or "depends on" can also help reduce Kconfig circular dependency issues. Therefore, change the use of "depends on REGMAP" to "select REGMAP". Fixes: ef0f62264b2a ("platform/x86: mlx-platform: Add physical bus number auto detection") Signed-off-by: Randy Dunlap Cc: Vadim Pasternak Cc: Darren Hart Cc: Hans de Goede Cc: Mark Gross Cc: platform-driver-x86@vger.kernel.org Link: https://lore.kernel.org/r/20230226053953.4681-7-rdunlap@infradead.org Signed-off-by: Hans de Goede Reviewed-by: Hans de Goede Signed-off-by: Sasha Levin

platform: mellanox: select REGMAP instead of depending on it

2023-03-17T07:50:27Z

[ Upstream commit 03f5eb300ad1241f854269a3e521b119189a4493 ] REGMAP is a hidden (not user visible) symbol. Users cannot set it directly thru "make *config", so drivers should select it instead of depending on it if they need it. Consistently using "select" or "depends on" can also help reduce Kconfig circular dependency issues. Therefore, change the use of "depends on REGMAP" to "select REGMAP". For NVSW_SN2201, select REGMAP_I2C instead of depending on it. Fixes: c6acad68eb2d ("platform/mellanox: mlxreg-hotplug: Modify to use a regmap interface") Fixes: 5ec4a8ace06c ("platform/mellanox: Introduce support for Mellanox register access driver") Fixes: 62f9529b8d5c ("platform/mellanox: mlxreg-lc: Add initial support for Nvidia line card devices") Fixes: 662f24826f95 ("platform/mellanox: Add support for new SN2201 system") Signed-off-by: Randy Dunlap Cc: Darren Hart Cc: Hans de Goede Cc: Michael Shych Cc: Mark Gross Cc: Vadim Pasternak Cc: platform-driver-x86@vger.kernel.org Link: https://lore.kernel.org/r/20230226053953.4681-6-rdunlap@infradead.org Signed-off-by: Hans de Goede Reviewed-by: Hans de Goede Signed-off-by: Sasha Levin

platform/chrome: cros_ec_typec: Update port DP VDO

2023-03-10T08:32:52Z

[ Upstream commit 8d2b28df6c3dc1581d856f52d9f78059ef2a568f ] The port advertising DP support is a Type-C receptacle. Fix the port's DisplayPort VDO to reflect this. Fixes: 1903adae0464 ("platform/chrome: cros_ec_typec: Add bit offset for DP VDO") Signed-off-by: Prashant Malani Reviewed-by: Benson Leung Acked-by: Heikki Krogerus Link: https://lore.kernel.org/r/20221228004648.793339-6-pmalani@chromium.org Signed-off-by: Sasha Levin

platform/x86: nvidia-wmi-ec-backlight: Add force module parameter

2023-02-25T10:25:43Z

commit 0d9bdd8a550170306c2021b8d6766c5343b870c2 upstream. On some Lenovo Legion models, the backlight might be driven by either one of nvidia_wmi_ec_backlight or amdgpu_bl0 at different times. When the Nvidia WMI EC backlight interface reports the backlight is controlled by the EC, the current backlight handling only registers nvidia_wmi_ec_backlight (and registers no other backlight interfaces). This hides (never registers) the amdgpu_bl0 interface, where as prior to 6.1.4 users would have both nvidia_wmi_ec_backlight and amdgpu_bl0 and could work around things in userspace. Add a force module parameter which can be used with acpi_backlight=native to restore the old behavior as a workound (for now) by passing: "acpi_backlight=native nvidia-wmi-ec-backlight.force=1" Fixes: 8d0ca287fd8c ("platform/x86: nvidia-wmi-ec-backlight: Use acpi_video_get_backlight_type()") Link: https://bugzilla.kernel.org/show_bug.cgi?id=217026 Cc: stable@vger.kernel.org Signed-off-by: Hans de Goede Reviewed-by: Daniel Dadap Link: https://lore.kernel.org/r/20230217144208.5721-1-hdegoede@redhat.com Signed-off-by: Greg Kroah-Hartman

platform/x86/amd/pmf: Add depends on CONFIG_POWER_SUPPLY

2023-02-25T10:25:43Z

commit 3004e8d2a0a98bbf4223ae146464fadbff68bf78 upstream. It is reported that amd_pmf driver is missing "depends on" for CONFIG_POWER_SUPPLY causing the following build error. ld: drivers/platform/x86/amd/pmf/core.o: in function `amd_pmf_remove': core.c:(.text+0x10): undefined reference to `power_supply_unreg_notifier' ld: drivers/platform/x86/amd/pmf/core.o: in function `amd_pmf_probe': core.c:(.text+0x38f): undefined reference to `power_supply_reg_notifier' make[1]: *** [scripts/Makefile.vmlinux:34: vmlinux] Error 1 make: *** [Makefile:1248: vmlinux] Error 2 Add this to the Kconfig file. Link: https://bugzilla.kernel.org/show_bug.cgi?id=217028 Fixes: c5258d39fc4c ("platform/x86/amd/pmf: Add helper routine to update SPS thermals") Signed-off-by: Shyam Sundar S K Link: https://lore.kernel.org/r/20230213121457.1764463-1-Shyam-sundar.S-k@amd.com Cc: stable@vger.kernel.org Reviewed-by: Hans de Goede Signed-off-by: Hans de Goede Signed-off-by: Greg Kroah-Hartman

platform/x86: touchscreen_dmi: Add Chuwi Vi8 (CWI501) DMI match

2023-02-22T11:59:45Z

[ Upstream commit eecf2acd4a580e9364e5087daf0effca60a240b7 ] Add a DMI match for the CWI501 version of the Chuwi Vi8 tablet, pointing to the same chuwi_vi8_data as the existing CWI506 version DMI match. Signed-off-by: Hans de Goede Link: https://lore.kernel.org/r/20230202103413.331459-1-hdegoede@redhat.com Signed-off-by: Sasha Levin

platform/x86/amd: pmc: add CONFIG_SERIO dependency

2023-02-09T10:28:26Z

commit abce209d18fd26e865b2406cc68819289db973f9 upstream. Using the serio subsystem now requires the code to be reachable: x86_64-linux-ld: drivers/platform/x86/amd/pmc.o: in function `amd_pmc_suspend_handler': pmc.c:(.text+0x86c): undefined reference to `serio_bus' Add the usual dependency: as other users of serio use 'select' rather than 'depends on', use the same here. Fixes: 8e60615e8932 ("platform/x86/amd: pmc: Disable IRQ1 wakeup for RN/CZN") Signed-off-by: Arnd Bergmann Link: https://lore.kernel.org/r/20230127093950.2368575-1-arnd@kernel.org Reviewed-by: Hans de Goede Signed-off-by: Hans de Goede Signed-off-by: Greg Kroah-Hartman

platform/x86/amd: pmc: Disable IRQ1 wakeup for RN/CZN

2023-02-09T10:28:13Z

[ Upstream commit 8e60615e8932167057b363c11a7835da7f007106 ] By default when the system is configured for low power idle in the FADT the keyboard is set up as a wake source. This matches the behavior that Windows uses for Modern Standby as well. It has been reported that a variety of AMD based designs there are spurious wakeups are happening where two IRQ sources are active. For example: ``` PM: Triggering wakeup from IRQ 9 PM: Triggering wakeup from IRQ 1 ``` In these designs IRQ 9 is the ACPI SCI and IRQ 1 is the keyboard. One way to trigger this problem is to suspend the laptop and then unplug the AC adapter. The SOC will be in a hardware sleep state and plugging in the AC adapter returns control to the kernel's s2idle loop. Normally if just IRQ 9 was active the s2idle loop would advance any EC transactions and no other IRQ being active would cause the s2idle loop to put the SOC back into hardware sleep state. When this bug occurred IRQ 1 is also active even if no keyboard activity occurred. This causes the s2idle loop to break and the system to wake. This is a platform firmware bug triggering IRQ1 without keyboard activity. This occurs in Windows as well, but Windows will enter "SW DRIPS" and then with no activity enters back into "HW DRIPS" (hardware sleep state). This issue affects Renoir, Lucienne, Cezanne, and Barcelo platforms. It does not happen on newer systems such as Mendocino or Rembrandt. It's been fixed in newer platform firmware. To avoid triggering the bug on older systems check the SMU F/W version and adjust the policy at suspend time for s2idle wakeup from keyboard on these systems. A lot of thought and experimentation has been given around the timing of disabling IRQ1, and to make it work the "suspend" PM callback is restored. Reported-by: Kai-Heng Feng Reported-by: Xaver Hugl Link: https://gitlab.freedesktop.org/drm/amd/-/issues/2115 Link: https://gitlab.freedesktop.org/drm/amd/-/issues/1951 Signed-off-by: Mario Limonciello Link: https://lore.kernel.org/r/20230120191519.15926-1-mario.limonciello@amd.com Reviewed-by: Hans de Goede Signed-off-by: Hans de Goede Signed-off-by: Sasha Levin

platform/x86: gigabyte-wmi: add support for B450M DS3H WIFI-CF

2023-02-09T10:28:13Z

[ Upstream commit a410429a3b7e748a9db9f357e71e2e085a21c902 ] To the best of my knowledge this is the same board as the B450M DS3H-CF, but with an added WiFi card. Name obtained using dmidecode, tested with force_load on v6.1.6 Signed-off-by: Kevin Kuriakose Acked-by: Thomas Weißschuh Link: https://lore.kernel.org/r/20230119150925.31962-1-kevinmkuriakose@gmail.com Reviewed-by: Hans de Goede Signed-off-by: Hans de Goede Signed-off-by: Sasha Levin

platform/x86: hp-wmi: Handle Omen Key event

2023-02-09T10:28:13Z

[ Upstream commit 3ee5447b2048c8389ed899838a40b40180d50906 ] Add support to map the "HP Omen Key" to KEY_PROG2. Laptops in the HP Omen Series open the HP Omen Command Center application on windows. But, on linux it fails with the following message from the hp-wmi driver: [ 5143.415714] hp_wmi: Unknown event_id - 29 - 0x21a5 Also adds support to map Fn+Esc to KEY_FN_ESC. This currently throws the following message on the hp-wmi driver: [ 6082.143785] hp_wmi: Unknown key code - 0x21a7 There is also a "Win-Lock" key on HP Omen Laptops which supports Enabling and Disabling the Windows key, which trigger commands 0x21a4 and 0x121a4 respectively, but I wasn't able to find any KEY in input.h to map this to. Signed-off-by: Rishit Bansal Link: https://lore.kernel.org/r/20230120221214.24426-1-rishitbansal0@gmail.com Reviewed-by: Hans de Goede Signed-off-by: Hans de Goede Signed-off-by: Sasha Levin