summaryrefslogtreecommitdiff
path: root/drivers/platform/x86/wmi.c
AgeCommit message (Collapse)Author
2024-05-16platform/x86: wmi: Remove custom EC address space handlerRafael J. Wysocki
The custom EC address space handler in the WMI driver was only needed because the EC driver did not install its address space handler for EC operation regions beyond the EC device scope in the ACPI namespace. That has just changed, so the custom EC address handler is not needed any more and it can be removed. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by: Armin Wolf <W_Armin@gmx.de> Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Reviewed-by: Hans de Goede <hdegoede@redhat.com> Reviewed-by: Mario Limonciello <mario.limonciello@amd.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
2024-03-25platform/x86: wmi: Avoid returning AE_OK upon unknown errorArmin Wolf
If an error code other than EINVAL, ENODEV or ETIME is returned by ec_read()/ec_write(), then AE_OK is wrongly returned. Fix this by only returning AE_OK if the return code is 0, and return AE_ERROR otherwise. Tested on a Dell Inspiron 3505 and a Asus Prime B650-Plus. Reviewed-by: Hans de Goede <hdegoede@redhat.com> Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Reviewed-by: Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com> Signed-off-by: Armin Wolf <W_Armin@gmx.de> Link: https://lore.kernel.org/r/20240314184538.2933-2-W_Armin@gmx.de Signed-off-by: Hans de Goede <hdegoede@redhat.com>
2024-03-25platform/x86: wmi: Support reading/writing 16 bit EC valuesArmin Wolf
The ACPI EC address space handler currently only supports reading/writing 8 bit values. Some firmware implementations however want to access for example 16 bit values, which is perfectly legal according to the ACPI spec. Add support for reading/writing such values. Tested on a Dell Inspiron 3505 and a Asus Prime B650-Plus. Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Armin Wolf <W_Armin@gmx.de> Reviewed-by: Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com> Link: https://lore.kernel.org/r/20240314184538.2933-1-W_Armin@gmx.de Signed-off-by: Hans de Goede <hdegoede@redhat.com>
2024-03-12platform/x86: wmi: Remove obsolete duplicate GUID allowlistArmin Wolf
The whitelist-based approach for preventing older WMI drivers from being instantiated multiple times has many drawbacks: - uses cannot see all available WMI devices (if not whitelisted) - whitelisting a WMI driver requires changes in the WMI driver core - maintenance burden for driver and subsystem developers Since the WMI driver core already takes care that older WMI drivers are not being instantiated multiple times, remove the now redundant whitelist. Tested on a ASUS Prime B650-Plus. Signed-off-by: Armin Wolf <W_Armin@gmx.de> Link: https://lore.kernel.org/r/20240226193557.2888-3-W_Armin@gmx.de Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
2024-03-12platform/x86: wmi: Do not instantiate older WMI drivers multiple timesArmin Wolf
Many older WMI drivers cannot be instantiated multiple times for two reasons: - they are using the legacy GUID-based WMI API - they are singletons (with global state) Prevent such WMI drivers from binding to WMI devices with a duplicated GUID, as this would mean that the WMI driver will be instantiated at least two times (one for the original GUID and one for the duplicated GUID). WMI drivers which can be instantiated multiple times can signal this by setting a flag inside struct wmi_driver. Tested on a ASUS Prime B650-Plus. Signed-off-by: Armin Wolf <W_Armin@gmx.de> Link: https://lore.kernel.org/r/20240226193557.2888-2-W_Armin@gmx.de Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
2024-03-12platform/x86: wmi: Ignore duplicated GUIDs in legacy matchesArmin Wolf
When matching a WMI device to a GUID used by the legacy GUID-based API, devices with a duplicated GUID should be ignored. Add an additional WMI device flag signaling that the GUID used by the WMI device is also used by another WMI device. Ignore such devices inside the match functions used by the legacy GUID-based API. Tested on a ASUS Prime B650-Plus. Signed-off-by: Armin Wolf <W_Armin@gmx.de> Link: https://lore.kernel.org/r/20240226193557.2888-1-W_Armin@gmx.de Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
2024-02-27platform/x86: wmi: Always evaluate _WED when receiving an eventArmin Wolf
The ACPI WMI specification states: "The _WED control method is evaluated by the mapper in response to receiving a notification from a control method." This means that _WED should be evaluated unconditionally even if no WMI event consumers are present. Some firmware implementations actually depend on this behavior by storing the event data inside a queue which will fill up if the WMI core stops retrieving event data items due to no consumers being present Fix this by always evaluating _WED even if no WMI event consumers are present. Signed-off-by: Armin Wolf <W_Armin@gmx.de> Link: https://lore.kernel.org/r/20240219115919.16526-4-W_Armin@gmx.de Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
2024-02-27platform/x86: wmi: Check if event data is not NULLArmin Wolf
WMI event drivers which do not have no_notify_data set expect that each WMI event contains valid data. Evaluating _WED however might return no data, which can cause issues with such drivers. Fix this by validating that evaluating _WED did return data. Signed-off-by: Armin Wolf <W_Armin@gmx.de> Link: https://lore.kernel.org/r/20240219115919.16526-3-W_Armin@gmx.de Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
2024-02-27platform/x86: wmi: Prevent incompatible event driver from probingArmin Wolf
If a WMI event driver has no_notify_data set, then it indicates support for WMI events which provide no notify data, otherwise the notify() callback expects a valid ACPI object as notify data. However if a WMI event driver which requires notify data is bound to a WMI event device which cannot retrieve such data due to the _WED ACPI method being absent, then the driver will be dysfunctional since all WMI events will be dropped due to the missing notify data. Fix this by not allowing such WMI event drivers to bind to WMI event devices which do not support retrieving of notify data. Also reword the description of no_notify_data a bit. Signed-off-by: Armin Wolf <W_Armin@gmx.de> Link: https://lore.kernel.org/r/20240219115919.16526-2-W_Armin@gmx.de Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
2024-02-13platform/x86: wmi: Make input buffer mandatory when evaluating methodsArmin Wolf
The ACPI-WMI specification declares in the section "ACPI Control Method Naming Conventions and Functionality for Windows 2000 Instrumentation" that a WMxx control method takes 3 arguments: instance, method id and argument buffer. This is also the case even when the underlying WMI method does not have any input arguments. So if a WMI driver evaluates a WMI method without passing an input buffer, ACPICA will log a warning complaining that the third argument is missing. Prevent this by checking that a input buffer was passed, and return an error if this was not the case. Tested on a Asus PRIME B650-Plus. Reviewed-by: Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com> Signed-off-by: Armin Wolf <W_Armin@gmx.de> Link: https://lore.kernel.org/r/20240212185016.5494-1-W_Armin@gmx.de Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
2024-02-08Merge tag 'platform-drivers-x86-v6.8-2' into pdx/for-nextIlpo Järvinen
Merge tag 'platform-drivers-x86-v6.8-2' fixes into pdf86/for-next because of WMI fixes. The WMI changes done in for-next already created a minor conflict with the fixes and WMI is actively being improved currently so besides resolving the current conflict, this is also to avoid further conflicts.
2024-02-07platform/x86: wmi: Replace pr_err() with dev_err()Armin Wolf
Using dev_err() allows users to find out from which device the error message came from. Signed-off-by: Armin Wolf <W_Armin@gmx.de> Link: https://lore.kernel.org/r/20240206220447.3102-4-W_Armin@gmx.de Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
2024-02-07platform/x86: wmi: Remove unnecessary out-of-memory messageArmin Wolf
If kzalloc() fails, an out-of-memory message is already printed. Remove the unnecessary second warning message. Signed-off-by: Armin Wolf <W_Armin@gmx.de> Link: https://lore.kernel.org/r/20240206220447.3102-3-W_Armin@gmx.de Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
2024-02-07platform/x86: wmi: Use FW_BUG when warning about missing control methodsArmin Wolf
A missing WQxx control method is a firmware bug and should be marked as such using FW_BUG so that users know that the issue is not a kernel issue. Since get_subobj_info() might fail even if the control method is present, we need to print the warning only if acpi_get_handle() fails. Signed-off-by: Armin Wolf <W_Armin@gmx.de> Link: https://lore.kernel.org/r/20240206220447.3102-2-W_Armin@gmx.de Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
2024-02-07platform/x86: wmi: Check if WMxx control method existsArmin Wolf
Some devices like the MSI GF63-12VF contain WMI method blocks without providing the necessary WMxx ACPI control methods. Avoid creating WMI devices for such WMI method blocks since the resulting WMI device is going to be unusable. Signed-off-by: Armin Wolf <W_Armin@gmx.de> Link: https://lore.kernel.org/r/20240206220447.3102-1-W_Armin@gmx.de Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
2024-02-06platform: x86: wmi: make wmi_bus_type constRicardo B. Marliere
Now that the driver core can properly handle constant struct bus_type, move the wmi_bus_type variable to be a constant structure as well, placing it into read-only memory which can not be modified at runtime. Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Suggested-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: "Ricardo B. Marliere" <ricardo@marliere.net> Reviewed-by: Armin Wolf <W_Armin@gmx.de> Link: https://lore.kernel.org/r/20240204-bus_cleanup-platform-drivers-x86-v1-1-1f0839b385c6@marliere.net Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
2024-02-06platform/x86: wmi: Stop using ACPI device classArmin Wolf
When an ACPI netlink event is received by acpid, the ACPI device class is passed as its first argument. But since the class string is not initialized during probe, an empty string is being passed: netlink: PNP0C14:01 000000d0 00000000 Fix this by passing a static string instead. Tested on a Dell Inspiron 3505. Signed-off-by: Armin Wolf <W_Armin@gmx.de> Link: https://lore.kernel.org/r/20240130221942.2770-1-W_Armin@gmx.de Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
2024-01-24platform/x86: wmi: Use ACPI device name in netlink eventArmin Wolf
The device name inside the ACPI netlink event is limited to 15 characters, so the WMI device name will get truncated. This can be observed with kacpimon when receiving an event from WMI device "9DBB5994-A997-11DA-B012-B622A1EF5492": netlink: 9DBB5994-A997- 000000d0 00000000 Fix this by using the shorter device name from the ACPI bus device instead. This still allows users to uniquely identify the WMI device by using the notify id (0xd0). Signed-off-by: Armin Wolf <W_Armin@gmx.de> Reviewed-by: Hans de Goede <hdegoede@redhat.com> Link: https://lore.kernel.org/r/20240121200824.2778-1-W_Armin@gmx.de Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
2024-01-22platform/x86: wmi: Fix wmi_dev_probe()Dan Carpenter
This has a reversed if statement so it accidentally disables the wmi method before returning. Fixes: 704af3a40747 ("platform/x86: wmi: Remove chardev interface") Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org> Reviewed-by: Armin Wolf <W_Armin@gmx.de> Link: https://lore.kernel.org/r/9c81251b-bc87-4ca3-bb86-843dc85e5145@moroto.mountain Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
2024-01-22platform/x86: wmi: Fix notify callback lockingArmin Wolf
When an legacy WMI event handler is removed, an WMI event could have called the handler just before it was removed, meaning the handler could still be running after wmi_remove_notify_handler() returns. Something similar could also happens when using the WMI bus, as the WMI core might still call the notify() callback from an WMI driver even if its remove() callback was just called. Fix this by introducing a rw semaphore which ensures that the event state of a WMI device does not change while the WMI core is handling an event for it. Tested on a Dell Inspiron 3505 and a Acer Aspire E1-731. Fixes: 1686f5444546 ("platform/x86: wmi: Incorporate acpi_install_notify_handler") Signed-off-by: Armin Wolf <W_Armin@gmx.de> Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Reviewed-by: Hans de Goede <hdegoede@redhat.com> Link: https://lore.kernel.org/r/20240103192707.115512-5-W_Armin@gmx.de Signed-off-by: Hans de Goede <hdegoede@redhat.com>
2024-01-22platform/x86: wmi: Decouple legacy WMI notify handlers from wmi_block_listArmin Wolf
Until now, legacy WMI notify handler functions where using the wmi_block_list, which did no refcounting on the returned WMI device. This meant that the WMI device could disappear at any moment, potentially leading to various errors. Fix this by using bus_find_device() which returns an actual reference to the found WMI device. Tested on a Dell Inspiron 3505 and a Acer Aspire E1-731. Signed-off-by: Armin Wolf <W_Armin@gmx.de> Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Reviewed-by: Hans de Goede <hdegoede@redhat.com> Link: https://lore.kernel.org/r/20240103192707.115512-4-W_Armin@gmx.de Signed-off-by: Hans de Goede <hdegoede@redhat.com>
2024-01-22platform/x86: wmi: Return immediately if an suitable WMI event is foundArmin Wolf
Commit 58f6425eb92f ("WMI: Cater for multiple events with same GUID") allowed legacy WMI notify handlers to be installed for multiple WMI devices with the same GUID. However this is useless since the legacy GUID-based interface is blacklisted from seeing WMI devices with duplicated GUIDs. Return immediately if a suitable WMI event is found in wmi_install/remove_notify_handler() since searching for other suitable events is pointless. Tested on a Dell Inspiron 3505 and a Acer Aspire E1-731. Signed-off-by: Armin Wolf <W_Armin@gmx.de> Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Reviewed-by: Hans de Goede <hdegoede@redhat.com> Link: https://lore.kernel.org/r/20240103192707.115512-3-W_Armin@gmx.de Signed-off-by: Hans de Goede <hdegoede@redhat.com>
2024-01-22platform/x86: wmi: Fix error handling in legacy WMI notify handler functionsArmin Wolf
When wmi_install_notify_handler()/wmi_remove_notify_handler() are unable to enable/disable the WMI device, they unconditionally return an error to the caller. When registering legacy WMI notify handlers, this means that the callback remains registered despite wmi_install_notify_handler() having returned an error. When removing legacy WMI notify handlers, this means that the callback is removed despite wmi_remove_notify_handler() having returned an error. Fix this by only warning when the WMI device could not be enabled. This behaviour matches the bus-based WMI interface. Tested on a Dell Inspiron 3505 and a Acer Aspire E1-731. Fixes: 58f6425eb92f ("WMI: Cater for multiple events with same GUID") Signed-off-by: Armin Wolf <W_Armin@gmx.de> Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Reviewed-by: Hans de Goede <hdegoede@redhat.com> Link: https://lore.kernel.org/r/20240103192707.115512-2-W_Armin@gmx.de Signed-off-by: Hans de Goede <hdegoede@redhat.com>
2024-01-12Merge tag 'hwmon-for-v6.8' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging Pull hwmon updates from Guenter Roeck: "New drivers: - pmbus: Support for MPS Multi-phase mp2856/mp2857 controller - pmbus: Support for MPS Multi-phase mp5990 - Driver for Gigabyte AORUS Waterforce AIO coolers Added support to existing drivers: - lm75: Support for AMS AS6200 temperature sensor - k10temp: Support for AMD Family 19h Model 8h - max31827: Support for max31828 and max31829 - sht3x: Support for sts3x - Add support for WMI SMM interface, and various related improvements. Add support for Optiplex 7000 - emc1403: Support for EMC1442 - npcm750-pwm-fan: Support for NPCM8xx - nct6775: Add support for 2 additional fan controls Minor improvements and bug fixes: - gigabyte_waterforce: Mark status report as received under a spinlock - aquacomputer_d5next: Remove unneeded CONFIG_DEBUG_FS #ifdef - gpio-fan: Convert txt bindings to yaml - smsc47m1: Various cleanups / improvements - corsair-cpro: use NULL instead of 0 - hp-wmi-sensors: Fix failure to load on EliteDesk 800 G6 - tmp513: Various cleanups - peci/dimmtemp: Bump timeout - pc87360: Bounds check data->innr usage - nct6775: Fix fan speed set failure in automatic mode - ABI: sysfs-class-hwmon: document various missing attributes - lm25066, max6650, nct6775: Use i2c_get_match_data() - aspeed-pwm-tacho: Fix -Wstringop-overflow warning" * tag 'hwmon-for-v6.8' of git://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging: (59 commits) hwmon: (gigabyte_waterforce) Mark status report as received under a spinlock hwmon: (lm75) Fix tmp112 default config hwmon: (lm75) Add AMS AS6200 temperature sensor dt-bindings: hwmon: (lm75) Add AMS AS6200 temperature sensor hwmon: (lm75) remove now-unused include hwmon: (pmbus) Add support for MPS Multi-phase mp2856/mp2857 controller dt-bindings: Add MP2856/MP2857 voltage regulator device hwmon: (aquacomputer_d5next) Remove unneeded CONFIG_DEBUG_FS #ifdef dt-bindings: hwmon: gpio-fan: Convert txt bindings to yaml hwmon: (k10temp) Add support for AMD Family 19h Model 8h hwmon: Add driver for Gigabyte AORUS Waterforce AIO coolers hwmon: (smsc47m1) Rename global platform device variable hwmon: (smsc47m1) Simplify device registration hwmon: (smsc47m1) Convert to platform remove callback returning void hwmon: (smsc47m1) Mark driver struct with __refdata to prevent section mismatch MAINTAINERS: Add maintainer for Baikal-T1 PVT hwmon driver hwmon: (sht3x) add sts3x support hwmon: (pmbus) Add ltc4286 driver dt-bindings: hwmon: Add lltc ltc4286 driver bindings hwmon: (max31827) Add custom attribute for resolution ...
2023-12-19platform/x86: wmi: Simplify get_subobj_info()Armin Wolf
All callers who call get_subobj_info() with **info being NULL should better use acpi_has_method() instead. Convert the only caller who does this to acpi_has_method() to drop the dummy info handling. Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Armin Wolf <W_Armin@gmx.de> Link: https://lore.kernel.org/r/20231218192420.305411-7-W_Armin@gmx.de Signed-off-by: Hans de Goede <hdegoede@redhat.com>
2023-12-19platform/x86: wmi: Decouple ACPI notify handler from wmi_block_listArmin Wolf
Currently, the ACPI notify handler searches all WMI devices for a matching WMI event device. This is inefficient since only WMI devices associated with the notified ACPI device need to be searched. Use the WMI bus device and device_for_each_child() to search for a matching WMI event device instead. Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Armin Wolf <W_Armin@gmx.de> Link: https://lore.kernel.org/r/20231218192420.305411-6-W_Armin@gmx.de Signed-off-by: Hans de Goede <hdegoede@redhat.com>
2023-12-19platform/x86: wmi: Create WMI bus device firstArmin Wolf
Create the WMI bus device first so that it can be used by the ACPI handlers. Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Armin Wolf <W_Armin@gmx.de> Link: https://lore.kernel.org/r/20231218192420.305411-5-W_Armin@gmx.de Signed-off-by: Hans de Goede <hdegoede@redhat.com>
2023-12-19platform/x86: wmi: Use devres for resource handlingArmin Wolf
Use devres for cleaning up the ACPI handlers and the WMI bus device to simplify the error handling. Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Armin Wolf <W_Armin@gmx.de> Link: https://lore.kernel.org/r/20231218192420.305411-4-W_Armin@gmx.de Signed-off-by: Hans de Goede <hdegoede@redhat.com>
2023-12-19platform/x86: wmi: Remove ACPI handlers after WMI devicesArmin Wolf
When removing the ACPI notify/address space handlers, the WMI devices are still active and might still depend on ACPI EC access or WMI events. Fix this by removing the ACPI handlers after all WMI devices associated with an ACPI device have been removed. Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Armin Wolf <W_Armin@gmx.de> Link: https://lore.kernel.org/r/20231218192420.305411-3-W_Armin@gmx.de Signed-off-by: Hans de Goede <hdegoede@redhat.com>
2023-12-19platform/x86: wmi: Remove unused variable in address space handlerArmin Wolf
The variable "i" is always zero and only used in shift operations. Remove it to make the code more readable. Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Armin Wolf <W_Armin@gmx.de> Link: https://lore.kernel.org/r/20231218192420.305411-2-W_Armin@gmx.de Signed-off-by: Hans de Goede <hdegoede@redhat.com>
2023-12-11hwmon: (dell-smm) Add support for WMI SMM interfaceArmin Wolf
Some Dell machines like the Dell Optiplex 7000 do not support the legacy SMM interface, but instead expect all SMM calls to be issued over a special WMI interface. Add support for this interface so users can control the fans on those machines. Tested-by: <serverror@serverror.com> Reviewed-by: Hans de Goede <hdegoede@redhat.com> Reviewed-by: Pali Rohár <pali@kernel.org> Signed-off-by: Armin Wolf <W_Armin@gmx.de> Link: https://lore.kernel.org/r/20231123004820.50635-8-W_Armin@gmx.de Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2023-12-11platform/x86: wmi: Remove chardev interfaceArmin Wolf
The design of the WMI chardev interface is broken: - it assumes that WMI drivers are not instantiated twice - it offers next to no abstractions, the WMI driver gets a raw byte buffer - it is only used by a single driver, something which is unlikely to change Since the only user (dell-smbios-wmi) has been migrated to his own ioctl interface, remove it. Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Armin Wolf <W_Armin@gmx.de> Link: https://lore.kernel.org/r/20231210202443.646427-6-W_Armin@gmx.de Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
2023-12-11platform/x86: wmi: Remove debug_event module paramArmin Wolf
Users can already listen to ACPI WMI events through the ACPI netlink interface. The old wmi_notify_debug() interface also uses the deprecated GUID-based interface. Remove it to make the event handling code more readable. Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Armin Wolf <W_Armin@gmx.de> Link: https://lore.kernel.org/r/20231210202443.646427-3-W_Armin@gmx.de Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
2023-12-11platform/x86: wmi: Remove debug_dump_wdg module paramArmin Wolf
The functionality of dumping WDG entries is better provided by userspace tools like "fwts wmi", which also does not suffer from garbled printk output caused by pr_cont(). Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Armin Wolf <W_Armin@gmx.de> Link: https://lore.kernel.org/r/20231210202443.646427-2-W_Armin@gmx.de Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
2023-12-11Merge tag 'platform-drivers-x86-v6.7-3' into pdx86/for-nextHans de Goede
Back merge pdx86 fixes into pdx86/for-next for further WMI work depending on some of the fixes. platform-drivers-x86 for v6.7-3 Highlights: - asus-wmi: Solve i8042 filter resource handling, input, and suspend issues - wmi: Skip zero instance WMI blocks to avoid issues with some laptops - mlxbf-bootctl: Differentiate dev/production keys - platform/surface: Correct serdev related return value to avoid leaking errno into userspace - Error checking fixes The following is an automated shortlog grouped by driver: asus-wmi: - Change q500a_i8042_filter() into a generic i8042-filter - disable USB0 hub on ROG Ally before suspend - Filter Volume key presses if also reported via atkbd - Move i8042 filter install to shared asus-wmi code mellanox: - Add null pointer checks for devm_kasprintf() - Check devm_hwmon_device_register_with_groups() return value mlxbf-bootctl: - correctly identify secure boot with development keys surface: aggregator: - fix recv_buf() return value wmi: - Skip blocks with zero instances
2023-11-30platform/x86: wmi: Skip blocks with zero instancesArmin Wolf
Some machines like the HP Omen 17 ck2000nf contain WMI blocks with zero instances, so any WMI driver which tries to handle the associated WMI device will fail. Skip such WMI blocks to avoid confusing any WMI drivers. Reported-by: Alexis Belmonte <alexbelm48@gmail.com> Closes: https://bugzilla.kernel.org/show_bug.cgi?id=218188 Fixes: bff431e49ff5 ("ACPI: WMI: Add ACPI-WMI mapping driver") Tested-by: Alexis Belmonte <alexbelm48@gmail.com> Signed-off-by: Armin Wolf <W_Armin@gmx.de> Link: https://lore.kernel.org/r/20231129181654.5800-1-W_Armin@gmx.de Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
2023-11-20platform/x86/intel/wmi: thunderbolt: Use bus-based WMI interfaceArmin Wolf
Currently, the driver still uses the legacy GUID-based interface to invoke WMI methods. Use the modern bus-based interface instead. Tested on a Lenovo E51-80. Signed-off-by: Armin Wolf <W_Armin@gmx.de> Link: https://lore.kernel.org/r/20231103182526.3524-4-W_Armin@gmx.de Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
2023-11-20platform/x86: intel-wmi-sbl-fw-update: Use bus-based WMI interfaceArmin Wolf
Currently, the driver was still using the deprecated GUID-based interface to query/set data blocks. Use the modern bus-based interface for this. Tested with a custom SSDT from the Intel Slim Bootloader project. Reviewed-by: Jithu Joseph <jithu.joseph@intel.com> Signed-off-by: Armin Wolf <W_Armin@gmx.de> Link: https://lore.kernel.org/r/20231103182526.3524-3-W_Armin@gmx.de Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
2023-11-20platform/x86: wmi: Add wmidev_block_set()Armin Wolf
Currently, WMI drivers have to use the deprecated GUID-based interface when setting data blocks. This prevents those drivers from fully moving away from this interface. Provide wmidev_block_set() so drivers using wmi_set_block() can fully migrate to the modern bus-based interface. Tested with a custom SSDT from the Intel Slim Bootloader project. Signed-off-by: Armin Wolf <W_Armin@gmx.de> Link: https://lore.kernel.org/r/20231103182526.3524-1-W_Armin@gmx.de Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
2023-10-25platform/x86: wmi: Decouple WMI device removal from wmi_block_listArmin Wolf
Use device_for_each_child_reverse() to find and unregister WMI devices belonging to a WMI bus device instead of iterating thru the entire wmi_block_list. Signed-off-by: Armin Wolf <W_Armin@gmx.de> Link: https://lore.kernel.org/r/20231020211005.38216-6-W_Armin@gmx.de Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
2023-10-25platform/x86: wmi: Fix opening of char deviceArmin Wolf
Since commit fa1f68db6ca7 ("drivers: misc: pass miscdevice pointer via file private data"), the miscdevice stores a pointer to itself inside filp->private_data, which means that private_data will not be NULL when wmi_char_open() is called. This might cause memory corruption should wmi_char_open() be unable to find its driver, something which can happen when the associated WMI device is deleted in wmi_free_devices(). Fix the problem by using the miscdevice pointer to retrieve the WMI device data associated with a char device using container_of(). This also avoids wmi_char_open() picking a wrong WMI device bound to a driver with the same name as the original driver. Fixes: 44b6b7661132 ("platform/x86: wmi: create userspace interface for drivers") Signed-off-by: Armin Wolf <W_Armin@gmx.de> Link: https://lore.kernel.org/r/20231020211005.38216-5-W_Armin@gmx.de Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
2023-10-25platform/x86: wmi: Fix probe failure when failing to register WMI devicesArmin Wolf
When a WMI device besides the first one somehow fails to register, retval is returned while still containing a negative error code. This causes the ACPI device fail to probe, leaving behind zombie WMI devices leading to various errors later. Handle the single error path separately and return 0 unconditionally after trying to register all WMI devices to solve the issue. Also continue to register WMI devices even if some fail to allocate memory. Fixes: 6ee50aaa9a20 ("platform/x86: wmi: Instantiate all devices before adding them") Signed-off-by: Armin Wolf <W_Armin@gmx.de> Link: https://lore.kernel.org/r/20231020211005.38216-4-W_Armin@gmx.de Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
2023-10-25platform/x86: wmi: Fix refcounting of WMI devices in legacy functionsArmin Wolf
Until now, legacy GUID-based functions where using find_guid() when searching for WMI devices, which did no refcounting on the returned WMI device. This meant that the WMI device could disappear at any moment, potentially leading to various errors. Fix this by using bus_find_device() which returns an actual reference to the found WMI device. Signed-off-by: Armin Wolf <W_Armin@gmx.de> Link: https://lore.kernel.org/r/20231020211005.38216-3-W_Armin@gmx.de Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
2023-10-25platform/x86: wmi: Decouple probe deferring from wmi_block_listArmin Wolf
Many aggregate WMI drivers do not use -EPROBE_DEFER when they cannot find a WMI device during probe, instead they require all WMI devices associated with an platform device to become available at once. This is currently achieved by adding those WMI devices to the wmi_block_list before they are registered, which is then used by the deprecated GUID-based functions to search for WMI devices. Replace this approach with a device link which defers probing of the WMI device until the associated platform device has finished probing (and has registered all WMI devices). New aggregate WMI drivers should not rely on this behaviour. Signed-off-by: Armin Wolf <W_Armin@gmx.de> Link: https://lore.kernel.org/r/20231020211005.38216-2-W_Armin@gmx.de Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
2023-07-10platform/x86: wmi: Replace open coded guid_parse_and_compare()Andy Shevchenko
Even though we have no issues in the code, let's replace the open coded guid_parse_and_compare(). Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://lore.kernel.org/r/20230621151155.78279-2-andriy.shevchenko@linux.intel.com Tested-by: Armin Wolf <W_Armin@gmx.de> Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
2023-07-10platform/x86: wmi: Break possible infinite loop when parsing GUIDAndy Shevchenko
The while-loop may break on one of the two conditions, either ID string is empty or GUID matches. The second one, may never be reached if the parsed string is not correct GUID. In such a case the loop will never advance to check the next ID. Break possible infinite loop by factoring out guid_parse_and_compare() helper which may be moved to the generic header for everyone later on and preventing from similar mistake in the future. Interestingly that firstly it appeared when WMI was turned into a bus driver, but later when duplicated GUIDs were checked, the while-loop has been replaced by for-loop and hence no mistake made again. Fixes: a48e23385fcf ("platform/x86: wmi: add context pointer field to struct wmi_device_id") Fixes: 844af950da94 ("platform/x86: wmi: Turn WMI into a bus driver") Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://lore.kernel.org/r/20230621151155.78279-1-andriy.shevchenko@linux.intel.com Tested-by: Armin Wolf <W_Armin@gmx.de> Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
2023-05-09platform/x86: wmi: Allow retrieving the number of WMI object instancesArmin Wolf
Currently, the WMI driver core knows how many instances of a given WMI object exist, but WMI drivers cannot access this information. At the same time, some current and upcoming WMI drivers want to have access to this information. Add wmi_instance_count() and wmidev_instance_count() to allow WMI drivers to get the number of WMI object instances. Signed-off-by: Armin Wolf <W_Armin@gmx.de> Link: https://lore.kernel.org/r/20230430203153.5587-2-W_Armin@gmx.de Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
2023-05-09platform/x86: wmi: Mark GUID-based WMI interface as deprecatedArmin Wolf
The WMI driver core supports a more mordern bus-based interface for interacting with WMI devices. The older GUID-based interface depends on each WMI GUID and notification id being unique on a given system, which turned out is not the case. Mark the older interface as deprecated since new WMI drivers should use the bus-based interface to avoid this issues. Signed-off-by: Armin Wolf <W_Armin@gmx.de> Tested-by: Randy Dunlap <rdunlap@infradead.org> Acked-by: Randy Dunlap <rdunlap@infradead.org> Link: https://lore.kernel.org/r/20230424222939.208137-3-W_Armin@gmx.de Signed-off-by: Hans de Goede <hdegoede@redhat.com>
2023-05-09platform/x86: wmi: Add kernel doc commentsArmin Wolf
Add kernel doc comments useful for documenting the functions/structs used to interact with the WMI driver core. Signed-off-by: Armin Wolf <W_Armin@gmx.de> Tested-by: Randy Dunlap <rdunlap@infradead.org> Acked-by: Randy Dunlap <rdunlap@infradead.org> Link: https://lore.kernel.org/r/20230424222939.208137-2-W_Armin@gmx.de Signed-off-by: Hans de Goede <hdegoede@redhat.com>
2023-03-07platform/x86: wmi: Convert to platform remove callback returning voidUwe Kleine-König
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is (mostly) ignored and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new() which already returns void. Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Link: https://lore.kernel.org/r/20230302144732.1903781-29-u.kleine-koenig@pengutronix.de Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com>