- 09 May, 2023 40 commits
-
-
Hans de Goede authored
Change the yogabook_wmi_ prefix of remaining generic (non WMI specific) symbols to yogabook_ . This is a preparation patch for making lenovo-yogabook-wmi also work on the Android version of the Yoga Book 1 which does not have a WMI interface to deal with toggling the keyboard half between touch-keyboard and wacom-digitizer mode. Signed-off-by:
Hans de Goede <hdegoede@redhat.com> Link: https://lore.kernel.org/r/20230430165807.472798-15-hdegoede@redhat.com
-
Hans de Goede authored
Add a yogabook_toggle_digitizer_mode() helper function. This is a preparation patch for making lenovo-yogabook-wmi also work on the Android version of the Yoga Book 1 which does not have a WMI interface to deal with toggling the keyboard half between touch-keyboard and wacom-digitizer mode. Signed-off-by:
-
Hans de Goede authored
Abstract kbd backlight setting. This is a preparation patch for making lenovo-yogabook-wmi also work on the Android version of the Yoga Book 1 which does not have a WMI interface to deal with toggling the keyboard half between touch-keyboard and wacom-digitizer mode. Signed-off-by:
-
Hans de Goede authored
lenovo-yogabook-wmi: controls the power-state itself and stores this in data->flags so there is no need to poke inside ACPI device internals. This is a preparation patch for making lenovo-yogabook-wmi also work on the Android version of the Yoga Book 1 which does not have a WMI interface to deal with toggling the keyboard half between touch-keyboard and wacom-digitizer mode. Signed-off-by:
-
Hans de Goede authored
Split probe() and remove() into generic and WMI specific parts. This is a preparation patch for making lenovo-yogabook-wmi also work on the Android version of the Yoga Book 1 which does not have a WMI interface to deal with toggling the keyboard half between touch-keyboard and wacom-digitizer mode. Signed-off-by:
-
Hans de Goede authored
Use the (new) PMIC LED driver for pen icon LED control instead of using custom WMI calls for this. This will also work on the Android version of the Lenovo Yoga Book 1, where there is no WMI interface for this. The dev_id of the lookup is set using dev_name() so that it will also work for both the Windows YB1 WMI-device as well as the Android YB1 platform-device. While at it also move the gpio_lookup to using dev_name() for the dev_id. Note this also removes the need to turn of the LED during suspend since the PMIC LED driver now already does that. Signed-off-by:
-
Hans de Goede authored
Add a "struct device *dev" local variable to probe(). This is a preparation patch for making lenovo-yogabook-wmi also work on the Android version of the Yoga Book 1 which does not have a WMI interface to deal with toggling the keyboard half between touch-keyboard and wacom-digitizer mode. While at it also move the dev_set_drvdata() call to the end of probe(). Signed-off-by:
-
Hans de Goede authored
Store a "struct device *dev" instead of a "struct wmi_device *wdev;" in the "struct yogabook_wmi" driver-data. This is a preparation patch for making lenovo-yogabook-wmi also work on the Android version of the Yoga Book 1 which does not have a WMI interface to deal with toggling the keyboard half between touch-keyboard and wacom-digitizer mode. Signed-off-by:
-
Hans de Goede authored
Switch to DEFINE_SIMPLE_DEV_PM_OPS() so that the __maybe_unused can be dropped from the suspend/resume callbacks. While at it also drop the _wmi_ part from the callback names in preparation for making lenovo-yogabook-wmi also work on the Android version of the Yoga Book 1 which does not have a WMI interface to deal with toggling the keyboard half between touch-keyboard and wacom-digitizer mode. Signed-off-by:
-
Hans de Goede authored
After the devm_gpiod_get("backside_hall_sw") call the gpio lookup table is no longer necessary. Remove it directly after this call instead using a devm reset-action for this. Signed-off-by: -
Hans de Goede authored
Set default keyboard backlight brightness on probe(), this fixes the backlight being off after a rmmod + modprobe. Fixes: c0549b72 ("platform/x86: lenovo-yogabook-wmi: Add driver for Lenovo Yoga Book") Signed-off-by:
-
Hans de Goede authored
Ensure that both the keyboard touchscreen and the digitizer have their driver bound after remove(). Without this modprobing lenovo-yogabook-wmi after a rmmod fails because lenovo-yogabook-wmi defers probing until both devices have their driver bound. Fixes: c0549b72 ("platform/x86: lenovo-yogabook-wmi: Add driver for Lenovo Yoga Book") Signed-off-by:
-
Hans de Goede authored
When yogabook_wmi_remove() runs yogabook_wmi_work might still be running and using the devices which yogabook_wmi_remove() puts. To avoid this move to explicitly cancelling the work rather then using devm_work_autocancel(). This requires also making the yogabook_backside_hall_irq handler non devm managed, so that it cannot re-queue the work while yogabook_wmi_remove() runs. Fixes: c0549b72 ("platform/x86: lenovo-yogabook-wmi: Add driver for Lenovo Yoga Book") Signed-off-by:
-
Thomas Weißschuh authored
Having to maintain a per-system allowlist is burdensome and confusing for users, drop it. Signed-off-by:
Thomas Weißschuh <linux@weissschuh.net> Link: https://lore.kernel.org/r/20230325-gigabyte-wmi-unrestrict-v2-1-0a54bc8e70d2@weissschuh.netReviewed-by:
-
Armin Wolf authored
The WMI driver core already knows how many WMI object instances are available, use this information instead of probing the WMI object manually. Compile-tested only. Signed-off-by:
Armin Wolf <W_Armin@gmx.de> Link: https://lore.kernel.org/r/20230430203153.5587-3-W_Armin@gmx.deReviewed-by:
-
Armin Wolf authored
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:
-
Hans de Goede authored
The Cyberbook T116 rugged tablet comes in both Windows and Android versions and even on the Android version the DSDT is mostly sane. This tablet has 2 extra general purpose buttons in the row with the power + volume-buttons, labeled P and F. Use the x86-android-tablets infra to create a gpio-button device for these 2 extra buttons. Signed-off-by:
Andy Shevchenko <andy.shevchenko@gmail.com> Link: https://lore.kernel.org/r/20230505205901.42649-2-hdegoede@redhat.com
-
Hans de Goede authored
Modify the gpio_keys support in x86_android_tablet_init() for tablets which have more then 1 key/button which needs to be handled by the gpio_keys driver. This requires copying over the struct gpio_keys_button from the x86_gpio_button struct array to a new gpio_keys_button struct array, as an added benefit this allows marking the per model x86_gpio_button arrays __initconst so that they all can be freed after module init(). Signed-off-by:
Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Link: https://lore.kernel.org/r/20230505205901.42649-1-hdegoede@redhat.com
-
Hans de Goede authored
Add x86_gpio_button info for the yb1-x90f/l describing the lid switch on the Lenovo Yoga Book Android models. Signed-off-by:
-
Hans de Goede authored
The Lenovo Yoga Book yb1-x90f/l has (another) bug in its DSDT where the UART resource for the BTH0 ACPI device contains "\\_SB.PCIO.URT1" as path to the UART. Note that is with a letter 'O' instead of the number '0' which is wrong. Add a x86_serdev_info entry to make the x86-android-tablets module manually setup the /sys/bus/serial device for the Bluetooth UART to fix Bluetooth not working due to this bug. Signed-off-by:
-
Hans de Goede authored
The Nextbook Ares 8A is a x86 ACPI tablet which ships with Android x86 as factory OS. Its DSDT contains a bunch of I2C devices which are not actually there, causing various resource conflicts. Enumeration of these is skipped through the acpi_quirk_skip_i2c_client_enumeration(). Add support for manually instantiating the I2C devices which are actually present on this tablet by adding the necessary device info to the x86-android-tablets module. Note the Ares 8A is the Cherry Trail (CHT) model, the regular Ares 8 is Bay Trail (BYT) based and was already supported. This also updates the comments for the BYT model to point out this is the BYT model. Signed-off-by:
-
Hans de Goede authored
Since commit 5adc4093 ("ACPI: x86: Introduce an acpi_quirk_skip_gpio_event_handlers() helper") the ACPI GPIO code will not register any GPIO event handlers at all for devices which have the ACPI_QUIRK_SKIP_GPIO_EVENT_HANDLERS set in their DMI table entry in drivers/acpi/x86/utils.c . This includes the Nextbook Ares 8 and the Asus ME176C and TF103C models, so x86-android-tablets no longer needs to disable the GPIO event handlers on these, since they have never been registered at all. Signed-off-by:
-
Hans de Goede authored
The Yoga Tablet 2 1050/830 series have an AL3320A ambient light sensor, add this to the list of i2c_clients to instantiate on these models. Signed-off-by:
-
Jonathan Singer authored
Previously, some support for certain keys on the HP keyboard has been added already in commit 3ee5447b ("platform/x86: hp-wmi: Handle Omen Key event"), however this as tested did not allow even the fn+esc key on my HP Envy which uses the same keycode on my HP Envy x360 laptop to work --the keycode rather than being passed in as a separate int from WMI, was being passed in as the event_data for the HPWMI_OMEN_KEY event. This patch, as tested was able to properly get the keycode for fn+esc, and for fn+f12 which is supposed to be a programmable key according to HP's keyboard diagram and is thus mapped to KEY_PROG2. The fn+f8 key combination (mute microphone) was a standard HPWMI_BEZEL_BUTTON key, however it did not previously have an entry in the sparse keymap. This patch preserves the original HPWMI_OMEN_KEY behavior for laptops that use it by only taking the keycode from the event_data only when the event_data is nonzero. Signed-off-by:
Jonathan Singer <jes965@nyu.edu> Reviewed-by:
Mario Limonciello <mario.limonciello@amd.com> Link: https://lore.kernel.org/r/20230426184852.2100-2-jes965@nyu.eduReviewed-by:
-
Jonathan Singer authored
Previously, when the camera toggle switch was hit, the hp-wmi driver would report an invalid event code. By adding a case for that in the event handling switch statement we can eliminate that error code and enable a framework for potential further kernel handling of that key. This change was tested on my HP Envy x360 15-ey0023dx laptop, but it would likely work for any HP laptop with a camera toggle button. Now we emit an SW_CAMERA_LENS_COVER event, on a device that gets created on the first such event so as to not report incorrectly the state of the camera shutter before we can know its state. Signed-off-by:
-
Srinivas Pandruvada authored
The new generation of CPUs have granular control at a cluster level. Each package/die can have multiple power domains, which further can have multiple fabric clusters. The TPMI interface allows control at fabric cluster level. Use the updated uncore sysfs feature to expose controls at cluster level. At each cluster level there is a control for maximum and minimum uncore frequency. Also present current uncore frequency at a cluster level. Signed-off-by:
Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Reviewed-by:
Zhang Rui <rui.zhang@intel.com> Tested-by:
Wendy Wang <wendy.wang@intel.com> Link: https://lore.kernel.org/r/20230418171340.681662-4-srinivas.pandruvada@linux.intel.comSigned-off-by:
-
Srinivas Pandruvada authored
An SoC can contain multiple power domains with individual or collection of mesh partitions. This partition is called fabric cluster. Certain type of meshes will need to run at the same frequency, they will be placed in the same fabric cluster. Benefit of fabric cluster is that it offers a scalable mechanism to deal with partitioned fabrics in a SoC. The current sysfs interface supports control at package and die level. This interface is not enough to support more granular control at fabric cluster level. SoCs with the support of TPMI (Topology Aware Register and PM Capsule Interface), can have multiple power domains. Each power domain can contain one or more fabric clusters. To support such granular controls, enhance uncore common to optionally create new directories to provide controls at fabric cluster level. It is also important to have flexibility to change granularity for future version of SoCs. If the directory name contains scope like: "package_*_die_*_power_domain_*_cluster_*", then this is not expandable. The cpufreq policies also have different scopes. There the scope of the policy (affected_cpus) specified by attributes inside each policy. So, follow the same model for uncore frequency scaling sysfs as: "sys/devices/system/cpu/cpufreq/policy*" Allow client drivers to optionally support granular control for each fabric cluster. Here, the directory name will be "uncore" suffixed with an unique instance number. For example: uncore00, uncore01 etc. Attributes in the directory identify package id, power domain and fabric cluster id. This interface is expandable even if some new level of granularity is introduced. A new sysfs attribute can identify new level. For compatibility with the existing sysfs and provide easy way to set limits for each fabric cluster in the package/die, the existing control at package/die levels are still provided. For majority of users, this is an easy approach. For example: On a single package/die system, with three power domains and one fabric cluster per power domain: $tree -L 2 /sys/devices/system/cpu/intel_uncore_frequency/ /sys/devices/system/cpu/intel_uncore_frequency/ ├── package_00_die_00 │ ├── current_freq_khz │ ├── initial_max_freq_khz │ ├── initial_min_freq_khz │ ├── max_freq_khz │ └── min_freq_khz ├── uncore00 │ ├── current_freq_khz │ ├── domain_id │ ├── fabric_cluster_id │ ├── initial_max_freq_khz │ ├── initial_min_freq_khz │ ├── max_freq_khz │ ├── min_freq_khz │ └── package_id ├── uncore01 │ ├── current_freq_khz │ ├── domain_id │ ├── fabric_cluster_id │ ├── initial_max_freq_khz │ ├── initial_min_freq_khz │ ├── max_freq_khz │ ├── min_freq_khz │ └── package_id └── uncore02 ├── current_freq_khz ├── domain_id ├── fabric_cluster_id ├── initial_max_freq_khz ├── initial_min_freq_khz ├── max_freq_khz ├── min_freq_khz └── package_id The attribute for cluster id is "fabric_cluster_id" instead of just "cluster_id" is to avoid confusion with usage of term clusters in other part of the Linux kernel. Signed-off-by: -
Srinivas Pandruvada authored
Implement support of uncore frequency control via TPMI (Topology Aware Register and PM Capsule Interface). This driver provides the similar functionality as the current uncore frequency driver using MSRs. The hardware interface to read/write is basically substitution of MSR 0x620 and 0x621. There are specific MMIO offset and bits to get/set minimum and maximum uncore ratio, similar to MSRs. The scope of the uncore MSRs is package/die. But new generation of CPUs have more granular control at a cluster level. Each package/die can have multiple power domains, which further can have multiple clusters. The TPMI interface allows control at cluster level. The primary use case for uncore sysfs is to set maximum and minimum uncore frequency to reduce power consumption or latency. The current uncore sysfs control is per package/die. This is enough for the majority of users as workload will move to different power domains as it moves between different CPUs. The current uncore sysfs provides controls at package/die level. When user sets maximum/minimum limits, the driver sets the same limits to each cluster. Here number of power domains = number of resources in this aux device. There are offsets and bits to discover number of clusters and offset for each cluster level controls. The TPMI documentation can be downloaded from: https://github.com/intel/tpmi_power_managementSigned-off-by:
-
Armin Wolf authored
Synchronize the ABI documentation with the driver documentation and direct users to the latter in case the search for more detailed information. Signed-off-by:
-
Armin Wolf authored
The WMI interface used by the dell-wmi-ddv driver contains many methods which are currently unused, making it difficult to document these inside the drivers source code. Create the necessary documentation based on current knowledge so that all details of the WMI interface can be written down for later use. Signed-off-by:
-
Armin Wolf authored
Add a place for device-specific documentation of WMI drivers. The first entry is documentation for the wmi-bmof driver, with additional documentation being expected to follow. Signed-off-by:
Randy Dunlap <rdunlap@infradead.org> Acked-by:
-
Armin Wolf authored
Add documentation for the WMI subsystem. The documentation describes both the ACPI WMI interface and the driver API for interacting with the WMI driver core. The information regarding the ACPI interface was retrieved from the Ubuntu kernel references and the Windows driver samples available on GitHub. The documentation is supposed to help driver developers writing WMI drivers, as many modern machines designed to run Windows provide an ACPI WMI interface. Signed-off-by:
-
Armin Wolf authored
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 authored
Add kernel doc comments useful for documenting the functions/structs used to interact with the WMI driver core. Signed-off-by:
-
Liming Sun authored
This commit adds memory barrier for the 'vq' update in function mlxbf_tmfifo_virtio_find_vqs() to avoid potential race due to out-of-order memory write. It also adds barrier for the 'is_ready' flag to make sure the initializations are visible before this flag is checked. Signed-off-by:
Liming Sun <limings@nvidia.com> Reviewed-by:
Vadim Pasternak <vadimp@nvidia.com> Link: https://lore.kernel.org/r/b98c0ab61d644ba38fa9b3fd1607b138b0dd820b.1682518748.git.limings@nvidia.comSigned-off-by:
-
Andrey Avdeev authored
Add touchscreen info for the Dexp Ursus KX210i Signed-off-by:
Andrey Avdeev <jamesstoun@gmail.com> Link: https://lore.kernel.org/r/ZE4gRgzRQCjXFYD0@avdeevavpc Cc: stable@vger.kernel.org Reviewed-by:
-
Hans de Goede authored
The Juno Computers Juno Tablet has an upside-down mounted Goodix touchscreen. Add a quirk to invert both axis to correct for this. Link: https://junocomputers.com/us/product/juno-tablet/ Cc: stable@vger.kernel.org Signed-off-by:
-
Mark Pearson authored
There has been a lot of confusion around which platform profiles are supported on various platforms and it would be useful to have a debug method to be able to override the profile mode that is selected. I don't expect this to be used in anything other than debugging in conjunction with Lenovo engineers - but it does give a way to get a system working whilst we wait for either FW fixes, or a driver fix to land upstream, if something is wonky in the mode detection logic Signed-off-by:
Mark Pearson <mpearson-lenovo@squebb.ca> Link: https://lore.kernel.org/r/20230505132523.214338-2-mpearson-lenovo@squebb.ca Cc: stable@vger.kernel.org Reviewed-by:
-
Mark Pearson authored
I had incorrectly thought that PSC profiles were not usable on Intel platforms so had blocked them in the driver initialistion. This broke platform profiles on the T490. After discussion with the FW team PSC does work on Intel platforms and should be allowed. Note - it's possible this may impact other platforms where it is advertised but special driver support that only Windows has is needed. But if it does then they will need fixing via quirks. Please report any issues to me so I can get them addressed - but I haven't found any problems in testing...yet Fixes: bce6243f ("platform/x86: thinkpad_acpi: do not use PSC mode on Intel platforms") Link: https://bugzilla.redhat.com/show_bug.cgi?id=2177962 Cc: stable@vger.kernel.org Signed-off-by:
-
Fae authored
Fixes micmute key of HP Envy X360 ey0xxx. Signed-off-by:
Fae <faenkhauser@gmail.com> Link: https://lore.kernel.org/r/20230425063644.11828-1-faenkhauser@gmail.com Cc: stable@vger.kernel.org Reviewed-by:
-
