- 28 Jun, 2022 6 commits
-
-
Hans de Goede authored
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: ed83c917 ("platform/x86: panasonic-laptop: Resolve hotkey double trigger bug") Reported-and-tested-by:
Stefan Seyfried <seife+kernel@b1-systems.com> Reported-and-tested-by:
Kenneth Chan <kenneth.t.chan@gmail.com> Signed-off-by:
Hans de Goede <hdegoede@redhat.com> Reviewed-by:
Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://lore.kernel.org/r/20220624112340.10130-7-hdegoede@redhat.com
-
Hans de Goede authored
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: ed83c917 ("platform/x86: panasonic-laptop: Resolve hotkey double trigger bug") Reported-and-tested-by:
-
Hans de Goede authored
In hindsight blindly throwing away most of the key-press events is not a good idea. So revert commit ed83c917 ("platform/x86: panasonic-laptop: Resolve hotkey double trigger bug"). Fixes: ed83c917 ("platform/x86: panasonic-laptop: Resolve hotkey double trigger bug") Reported-and-tested-by:
-
Hans de Goede authored
Sort includes alphabetically, small cleanup patch in preparation of further changes. Fixes: ed83c917 ("platform/x86: panasonic-laptop: Resolve hotkey double trigger bug") Signed-off-by:
-
Stefan Seyfried authored
In the definition of panasonic_keymap[] the key codes are given in decimal, later checks are done with hexadecimal values, which does not help in understanding the code. Additionally use two helper variables to shorten the code and make the logic more obvious. Fixes: ed83c917 ("platform/x86: panasonic-laptop: Resolve hotkey double trigger bug") Signed-off-by:
-
Hans de Goede authored
Some systems have an ACPI video bus but not ACPI video devices with backlight capability. On these devices brightness key-presses are (logically) not reported through the ACPI video bus. Change how acpi_video_handles_brightness_key_presses() determines if brightness key-presses are handled by the ACPI video driver to avoid vendor specific drivers/platform/x86 drivers filtering out their brightness key-presses even though they are the only ones reporting these presses. Fixes: ed83c917 ("platform/x86: panasonic-laptop: Resolve hotkey double trigger bug") Reported-and-tested-by:
Rafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by:
-
- 27 Jun, 2022 10 commits
-
-
Hans de Goede authored
The Ideapad 5 15ITL05 uses DYTC version 4 for platform-profile control. This has been tested successfully with the ideapad-laptop DYTC version 5 code; Add the Ideapad 5 15ITL05 to the ideapad_dytc_v4_allow_table[]. Fixes: 599482c5 ("platform/x86: ideapad-laptop: Add platform support for Ideapad 5 Pro 16ACH6-82L5") Link: https://bugzilla.kernel.org/show_bug.cgi?id=213297Signed-off-by:
-
Hans de Goede authored
Add an allow_v4_dytc module parameter to allow users to easily test if DYTC version 4 platform-profiles work on their laptop. Fixes: 599482c5 ("platform/x86: ideapad-laptop: Add platform support for Ideapad 5 Pro 16ACH6-82L5") Link: https://bugzilla.kernel.org/show_bug.cgi?id=213297Signed-off-by:
-
Jean Delvare authored
Unlike release_mem_region(), a call to release_resource() does not free the resource, so it has to be freed explicitly to avoid a memory leak. Signed-off-by:
Jean Delvare <jdelvare@suse.de> Fixes: 455cd867 ("platform/x86: thinkpad_acpi: Add a s2idle resume quirk for a number of laptops") Cc: Mario Limonciello <mario.limonciello@amd.com> Cc: Henrique de Moraes Holschuh <hmh@hmh.eng.br> Cc: Hans de Goede <hdegoede@redhat.com> Cc: Mark Gross <markgross@kernel.org> Reviewed-by:
Mario Limonciello <mario.limonciello@amd.com> Link: https://lore.kernel.org/r/20220621155511.5b266395@endymion.delvareSigned-off-by:
-
Hans de Goede authored
platform/x86/dell/Kconfig is only sourced if X86_PLATFORM_DEVICES is set, so it does not need to depend on it. Reviewed-by:
Andy Shevchenko <andy.shevchenko@gmail.com> Signed-off-by:
-
Hans de Goede authored
drivers/platform/x86/Kconfig is wrapped in one big if X86_PLATFORM_DEVICES .. endif and X86_PLATFORM_DEVICES already has a "depends on X86" so the "if X86" in drivers/platform/Kconfig is not necessary and except for MIPS none of the other includes there has such an if. So let's remove it. While at it also move the x86/Kconfig include to the end of the file for alphabetical sorting. Signed-off-by:
-
Hans de Goede authored
ACER_WMI already depends on ACPI_WMI which depends on ACPI so the "depends on ACPI" is unnecessary. And since ACER_WMI already depends on ACPI adding an "if ACPI" to the ACPI_VIDEO select is nonsense. While at it also group all the selects together. Reviewed-by:
-
Andy Shevchenko authored
Replace enabled(), onoff() and other similar places by str_*() helpers. Signed-off-by:
-
Andy Shevchenko authored
It's quite hard to understand in that zillions of headers that are included if any specific one is already listed. Sort headers for better maintenance. Signed-off-by:
-
Dan Carpenter authored
This should return PTR_ERR() instead of IS_ERR(). Also "dev->client" has been set to NULL by this point so it returns 0/success so preserve the error code earlier. Fixes: 662f2482 ("platform/mellanox: Add support for new SN2201 system") Signed-off-by:
Dan Carpenter <dan.carpenter@oracle.com> Acked-by:
Michael Shych <michaelsh@nvidia.com> Link: https://lore.kernel.org/r/YqmUGwmPK7cPolk/@kiliReviewed-by:
-
Gayatri Kammela authored
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 <srinivas.pandruvada@intel.com> Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Cc: David E. Box <david.e.box@linux.intel.com> Signed-off-by:
Gayatri Kammela <gayatri.kammela@linux.intel.com> Reviewed-by:
Rajneesh Bhardwaj <irenic.rajneesh@gmail.com> Link: https://lore.kernel.org/r/20220615002751.3371730-1-gayatri.kammela@linux.intel.comReviewed-by:
-
- 22 Jun, 2022 11 commits
-
-
Maximilian Luz authored
With the introduction of the Surface Laptop Studio, more event- and target categories have been added. Therefore, increase the number of reserved events and extend the enum of know target categories to accommodate this. Signed-off-by:
Maximilian Luz <luzmaximilian@gmail.com> Link: https://lore.kernel.org/r/20220614194117.4118897-1-luzmaximilian@gmail.comReviewed-by:
-
Tetsuo Handa authored
Use local wq in order to avoid flush_scheduled_work() usage. Signed-off-by:
Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> Reviewed-by:
-
Shyam Sundar S K authored
Currently, AMD supported platform drivers are grouped under generic "x86" folder structure. Move the current drivers (amd-pmc and amd_hsmp) to a separate directory. This would also mean the newer driver submissions to pdx86 subsystem in the future will also land in AMD specific directory. Reviewed-by:
Naveen Krishna Chatradhi <NaveenKrishna.Chatradhi@amd.com> Tested-by:
Suma Hegde <suma.hegde@amd.com> Signed-off-by:
Shyam Sundar S K <Shyam-sundar.S-k@amd.com> Link: https://lore.kernel.org/r/20220608193212.2827257-1-Shyam-sundar.S-k@amd.comReviewed-by:
-
Stephen Kitt authored
Instead of retrieving the backlight brightness in struct backlight_properties manually, and then checking whether the backlight should be on at all, use backlight_get_brightness() which does all this and insulates this from future changes. Signed-off-by:
Stephen Kitt <steve@sk2.org> Cc: Henrique de Moraes Holschuh <hmh@hmh.eng.br> Cc: Hans de Goede <hdegoede@redhat.com> Cc: Mark Gross <markgross@kernel.org> Cc: ibm-acpi-devel@lists.sourceforge.net Cc: platform-driver-x86@vger.kernel.org Reviewed-by:
Daniel Thompson <daniel.thompson@linaro.org> Link: https://lore.kernel.org/r/20220607184635.1127913-5-steve@sk2.orgReviewed-by:
-
Stephen Kitt authored
Instead of manually checking the power state in struct backlight_properties, use backlight_is_blank(). Signed-off-by:
-
Stephen Kitt authored
Instead of retrieving the backlight brightness in struct backlight_properties manually, and then checking whether the backlight should be on at all, use backlight_get_brightness() which does all this and insulates this from future changes. Signed-off-by:
-
Stephen Kitt authored
Instead of retrieving the backlight brightness in struct backlight_properties manually, and then checking whether the backlight should be on at all, use backlight_get_brightness() which does all this and insulates this from future changes. Signed-off-by:
-
Mark Pearson authored
By default the ACPI platform profile starts in balanced mode. On supported systems AMT is supposed to be enabled in balanced mode by default. When checking the capabilities during initialization, set up AMT to be enabled if it's supported. Co-developed-by:
Mark Pearson <markpearson@lenovo.com> Link: https://lore.kernel.org/r/20220603170212.164963-4-markpearson@lenovo.comReviewed-by:
-
Mark Pearson authored
On some AMD platforms if you press FN+T it will toggle whether automatic mode transitions are active. Recognize this keycode and use it to toggle AMT. Co-developed-by:
-
Mark Pearson authored
Some AMD Thinkpads support automatic mode transitions. The actual transition logic doesn't live in the `thinkpad_acpi` driver. The events to activate this logic come from this driver though. Populate these events when switching PSC power modes. Co-developed-by:
-
Mark Pearson authored
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:
-
- 13 Jun, 2022 12 commits
-
-
Maximilian Luz authored
Add support for the detachable keyboard cover on the Surface Pro 8. The keyboard cover on the Surface Pro 8 is, unlike the keyboard covers of earlier Surface Pro generations, handled via the Surface System Aggregator Module (SSAM). The keyboard and touchpad (as well as other HID input devices) of this cover are standard SSAM HID client devices (just like keyboard and touchpad on e.g. the Surface Laptop 3 and 4), however, some care needs to be taken as they can be physically detached (similarly to the Surface Book 3). Specifically, the respective SSAM client devices need to be removed when the keyboard cover has been detached and (re-)initialized when the keyboard cover has been (re-)attached. On the Surface Pro 8, detachment of the keyboard cover (and by extension its devices) is managed via the KIP subsystem. Therefore, said devices need to be registered under the KIP device hub, which in turn will remove and re-create/re-initialize those devices as needed. Signed-off-by:
-
Maximilian Luz authored
Add a Surface System Aggregator Module (SSAM) client device hub for hot-removable devices managed via the KIP subsystem. The KIP subsystem (full name unknown, abbreviation has been obtained through reverse engineering) is a subsystem that manages hot-removable SSAM client devices. Specifically, it manages HID input devices contained in the detachable keyboard cover of the Surface Pro 8 and Surface Pro X. The KIP subsystem handles a single group of devices (e.g. all devices contained in the keyboard cover) and cannot handle devices individually. Thus we model it as a client device hub, which (hot-)removes all devices contained under it once removal of the hub (e.g. keyboard cover) has been detected and (re-)adds all devices once the physical hub device has been (re-)attached. To do this, use the previously generified SSAM subsystem hub framework. Signed-off-by:
-
Maximilian Luz authored
Use the target category of the (base) hub as instance id in the (virtual) hub device UID. This makes association of the hub with the respective subsystem easier. Signed-off-by:
-
Maximilian Luz authored
The Surface System Aggregator Module (SSAM) has multiple subsystems that can manage detachable devices. At the moment, we only support the "base" (BAS/0x11) subsystem, which is used on the Surface Book 3 to manage devices (including keyboard, touchpad, and secondary battery) connected to the base of the device. The Surface Pro 8 has a new type-cover with keyboard and touchpad, which is managed via the KIP/0x0e subsystem. The general procedure is the same, but with slightly different events and setup. To make implementation of the KIP hub easier and prevent duplication, generify the parts of the base hub that we can use for the KIP hub (or any potential future subsystem hubs). This also switches over to use the newly introduced "hot-remove" functionality, which should prevent communication issues when devices have been detached. Lastly, also drop the undocumented and unused sysfs "state" attribute of the base hub. It has at best been useful for debugging. Signed-off-by:
-
Maximilian Luz authored
The KIP subsystem (full name unknown, abbreviation has been obtained through reverse engineering) handles detachable peripherals such as the keyboard cover on the Surface Pro X and Surface Pro 8. It is currently not entirely clear what this subsystem entails, but at the very least it provides event notifications for when the keyboard cover on the Surface Pro X and Surface Pro 8 have been detached or re-attached, as well as the state that the keyboard cover is currently in (e.g. folded-back, folded laptop-like, closed, etc.). Signed-off-by:
-
Maximilian Luz authored
Add support for hot-removal of SSAM HID client devices. Once a device has been hot-removed, further communication with it should be avoided as it may fail and time out. While the device will be removed as soon as we detect hot-removal, communication may still occur during teardown, especially when unregistering notifiers. While hot-removal is a surprise event that can happen at any time, try to avoid communication as much as possible once it has been detected to prevent timeouts that can slow down device removal and cause issues, e.g. when quickly re-attaching the device. Signed-off-by:
-
Maximilian Luz authored
Use newly introduced client device wrapper functions for notifier registration and unregistration. Signed-off-by:
Sebastian Reichel <sebastian.reichel@collabora.com> Link: https://lore.kernel.org/r/20220527023447.2460025-7-luzmaximilian@gmail.comReviewed-by:
-
Maximilian Luz authored
Use newly introduced client device wrapper functions for notifier registration and unregistration. Signed-off-by:
-
Maximilian Luz authored
Use newly introduced client device wrapper functions for notifier registration and unregistration. Signed-off-by:
-
Maximilian Luz authored
When SSAM client devices have been (physically) hot-removed, communication attempts with those devices may fail and time out. This can even extend to event notifiers, due to which timeouts may occur during device removal, slowing down that process. Add a parameter to the notifier unregister function that allows skipping communication with the EC to prevent this. Furthermore, add wrappers for registering and unregistering notifiers belonging to SSAM client devices that automatically check if the device has been marked as hot-removed and communication should be avoided. Note that non-SSAM client devices can generally not be hot-removed, so also add a convenience wrapper for those, defaulting to allow communication. Signed-off-by:
-
Maximilian Luz authored
Some SSAM devices, notably the keyboard cover (keyboard and touchpad) on the Surface Pro 8, can be hot-removed. When this occurs, communication with the device may fail and time out. This timeout can unnecessarily block and slow down device removal and even cause issues when the devices are detached and re-attached quickly. Thus, communication should generally be avoided once hot-removal is detected. While we already remove a device as soon as we detect its (hot-)removal, the corresponding device driver may still attempt to communicate with the device during teardown. This is especially critical as communication failure may also extend to disabling of events, which is typically done at that stage. Add a flag to allow marking devices as hot-removed. This can then be used during client driver teardown to check if any communication attempts should be avoided. Signed-off-by:
-
Maximilian Luz authored
platform/surface: aggregator: Allow is_ssam_device() to be used when CONFIG_SURFACE_AGGREGATOR_BUS is disabled In SSAM subsystem drivers that handle both ACPI and SSAM-native client devices, we may want to check whether we have a SSAM (native) client device. Further, we may want to do this even when instantiation thereof cannot happen due to CONFIG_SURFACE_AGGREGATOR_BUS=n. Currently, doing so causes an error due to an undefined reference error due to ssam_device_type being placed in the bus source unit. Therefore, if CONFIG_SURFACE_AGGREGATOR_BUS is not defined, simply let is_ssam_device() return false to prevent this error. Signed-off-by:
-
- 12 Jun, 2022 1 commit
-
-
Haowen Bai authored
Eliminate direct accesses to the driver_data field. Signed-off-by:
Haowen Bai <baihaowen@meizu.com> Link: https://lore.kernel.org/r/1653989063-20180-1-git-send-email-baihaowen@meizu.comReviewed-by:
-
