kernel/linux.git/include/linux/platform_data, branch v5.10.228

platform/x86: asus-wmi: Add support for ROG X13 tablet mode

2023-12-13T17:26:57+00:00

[ Upstream commit e397c3c460bf3849384f2f55516d1887617cfca9 ] Add quirk for ASUS ROG X13 Flow 2-in-1 to enable tablet mode with lid flip (all screen rotations). Signed-off-by: Luke D. Jones Link: https://lore.kernel.org/r/20220813092753.6635-2-luke@ljones.dev Reviewed-by: Hans de Goede Signed-off-by: Hans de Goede Stable-dep-of: b52cbca22cbf ("platform/x86: asus-wmi: Move i8042 filter install to shared asus-wmi code") Signed-off-by: Sasha Levin

asus-wmi: Add dgpu disable method

2023-12-13T17:26:57+00:00

[ Upstream commit 98829e84dc67630efb7de675f0a70066620468a3 ] In Windows the ASUS Armory Crate program can enable or disable the dGPU via a WMI call. This functions much the same as various Linux methods in software where the dGPU is removed from the device tree. However the WMI call saves the state of dGPU (enabled or not) and this then changes the dGPU visibility in Linux with no way for Linux users to re-enable it. We expose the WMI method so users can see and change the dGPU ACPI state. Signed-off-by: Luke D. Jones Link: https://lore.kernel.org/r/20210807023656.25020-3-luke@ljones.dev Reviewed-by: Hans de Goede Signed-off-by: Hans de Goede Stable-dep-of: b52cbca22cbf ("platform/x86: asus-wmi: Move i8042 filter install to shared asus-wmi code") Signed-off-by: Sasha Levin

platform/x86: asus-wmi: Add support for SW_TABLET_MODE on UX360

2023-12-13T17:26:57+00:00

[ Upstream commit ea856ec266c1e6aecd2b107032d5b5d661f0686d ] The UX360CA has a WMI device id 0x00060062, which reports whether the lid is flipped in tablet mode (1) or in normal laptop mode (0). Add a quirk (quirk_asus_use_lid_flip_devid) for devices on which this WMI device should be used to figure out the SW_TABLET_MODE state, as opposed to the quirk_asus_use_kbd_dock_devid. Additionally, the device needs to be queried on resume and restore because the firmware does not generate an event if the laptop is put to sleep while in tablet mode, flipped to normal mode, and later awoken. It is assumed other UX360* models have the same WMI device. As such, the quirk is applied to devices with DMI_MATCH(DMI_PRODUCT_NAME, "UX360"). More devices with this feature need to be tested and added accordingly. The reason for using an allowlist via the quirk mechanism is that the new WMI device (0x00060062) is also present on some models which do not have a 360 degree hinge (at least FX503VD and GL503VD from Hans' DSTS collection) and therefore its presence cannot be relied on. Signed-off-by: Samuel Čavoj Cc: Hans de Goede Link: https://lore.kernel.org/r/20201020220944.1075530-1-samuel@cavoj.net Reviewed-by: Hans de Goede Signed-off-by: Hans de Goede Stable-dep-of: b52cbca22cbf ("platform/x86: asus-wmi: Move i8042 filter install to shared asus-wmi code") Signed-off-by: Sasha Levin

ASoC: Intel: Move soc_intel_is_foo() helpers to a generic header

2023-12-08T07:46:14+00:00

[ Upstream commit cd45c9bf8b43cd387e167cf166ae5c517f56d658 ] The soc_intel_is_foo() helpers from sound/soc/intel/common/soc-intel-quirks.h are useful outside of the sound subsystem too. Move these to include/linux/platform_data/x86/soc.h, so that other code can use them too. Suggested-by: Andy Shevchenko Reviewed-by: Andy Shevchenko Acked-by: Mark Brown Signed-off-by: Hans de Goede Link: https://lore.kernel.org/r/20211018143324.296961-2-hdegoede@redhat.com Stable-dep-of: 7dd692217b86 ("ASoC: SOF: sof-pci-dev: Fix community key quirk detection") Signed-off-by: Sasha Levin

mtd: spi-nor: intel-spi: Disable write protection only if asked

2022-11-25T16:45:41+00:00

[ Upstream commit cd149eff8d2201a63c074a6d9d03e52926aa535d ] Currently the driver tries to disable the BIOS write protection automatically even if this is not what the user wants. For this reason modify the driver so that by default it does not touch the write protection. Only if specifically asked by the user (setting writeable=1 command line parameter) the driver tries to disable the BIOS write protection. Signed-off-by: Mika Westerberg Reviewed-by: Andy Shevchenko Reviewed-by: Mauro Lima Reviewed-by: Tudor Ambarus Acked-by: Lee Jones Link: https://lore.kernel.org/r/20220209122706.42439-2-mika.westerberg@linux.intel.com Signed-off-by: Mark Brown Stable-dep-of: 92a66cbf6b30 ("spi: intel: Use correct mask for flash and protected regions") Signed-off-by: Sasha Levin

platform/x86: pmc_atom: Fix SLP_TYPx bitfield mask

2022-09-08T09:11:36+00:00

[ Upstream commit 0a90ed8d0cfa29735a221eba14d9cb6c735d35b6 ] On Intel hardware the SLP_TYPx bitfield occupies bits 10-12 as per ACPI specification (see Table 4.13 "PM1 Control Registers Fixed Hardware Feature Control Bits" for the details). Fix the mask and other related definitions accordingly. Fixes: 93e5eadd1f6e ("x86/platform: New Intel Atom SOC power management controller driver") Signed-off-by: Andy Shevchenko Link: https://lore.kernel.org/r/20220801113734.36131-1-andriy.shevchenko@linux.intel.com Reviewed-by: Hans de Goede Signed-off-by: Hans de Goede Signed-off-by: Sasha Levin

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

2022-06-09T08:21:14+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

bus: ti-sysc: Add quirk handling for reinit on context lost

2021-11-26T09:39:08+00:00

[ Upstream commit 9d881361206ebcf6285c2ec2ef275aff80875347 ] Some interconnect target modules such as otg and gpmc on am335x need a re-init after resume. As we also have PM runtime cases where the context may be lost, let's handle these all with cpu_pm. For the am335x resume path, we already have cpu_pm_resume() call cpu_pm_cluster_exit(). Signed-off-by: Tony Lindgren Signed-off-by: Sasha Levin

bus: ti-sysc: Fix am335x resume hang for usb otg module

2021-06-10T11:39:21+00:00

[ Upstream commit 4d7b324e231366ea772ab10df46be31273ca39af ] On am335x, suspend and resume only works once, and the system hangs if suspend is attempted again. However, turns out suspend and resume works fine multiple times if the USB OTG driver for musb controller is loaded. The issue is caused my the interconnect target module losing context during suspend, and it needs a restore on resume to be reconfigure again as debugged earlier by Dave Gerlach . There are also other modules that need a restore on resume, like gpmc as noted by Dave. So let's add a common way to restore an interconnect target module based on a quirk flag. For now, let's enable the quirk for am335x otg only to fix the suspend and resume issue. As gpmc is not causing hangs based on tests with BeagleBone, let's patch gpmc separately. For gpmc, we also need a hardware reset done before restore according to Dave. To reinit the modules, we decouple system suspend from PM runtime. We replace calls to pm_runtime_force_suspend() and pm_runtime_force_resume() with direct calls to internal functions and rely on the driver internal state. There no point trying to handle complex system suspend and resume quirks via PM runtime. This is issue should have already been noticed with commit 1819ef2e2d12 ("bus: ti-sysc: Use swsup quirks also for am335x musb") when quirk handling was added for am335x otg for swsup. But the issue went unnoticed as having musb driver loaded hides the issue, and suspend and resume works once without the driver loaded. Fixes: 1819ef2e2d12 ("bus: ti-sysc: Use swsup quirks also for am335x musb") Suggested-by: Dave Gerlach Signed-off-by: Tony Lindgren Signed-off-by: Sasha Levin

gpio: omap: Save and restore sysconfig

2021-04-28T11:39:59+00:00

[ Upstream commit ddd8d94ca31e768c76cf8bfe34ba7b10136b3694 ] As we are using cpu_pm to save and restore context, we must also save and restore the GPIO sysconfig register. This is needed because we are not calling PM runtime functions at all with cpu_pm. We need to save the sysconfig on idle as it's value can get reconfigured by PM runtime and can be different from the init time value. Device specific flags like "ti,no-idle-on-init" can affect the init value. Fixes: b764a5863fd8 ("gpio: omap: Remove custom PM calls and use cpu_pm instead") Cc: Aaro Koskinen Cc: Adam Ford Cc: Andreas Kemnade Cc: Grygorii Strashko Cc: Peter Ujfalusi Signed-off-by: Tony Lindgren Acked-by: Grygorii Strashko Signed-off-by: Bartosz Golaszewski Signed-off-by: Sasha Levin