- 16 Nov, 2022 21 commits
-
-
Philipp Jungkamp authored
The event data of the WMI event 0xD0, which is assumed to be the fn_lock, is used to indicate several special keys on newer Yoga 7/9 laptops. The notify_id 0xD0 is non-unique in the DSDT of the Yoga 9 14IAP7, this causes wmi_get_event_data() to report wrong values. Port the ideapad-laptop WMI code to the wmi bus infrastructure which does not suffer from the shortcomings of wmi_get_event_data(). Signed-off-by:
Philipp Jungkamp <p.jungkamp@gmx.net> Link: https://lore.kernel.org/r/20221116110647.3438-1-p.jungkamp@gmx.netReviewed-by:
Hans de Goede <hdegoede@redhat.com> Signed-off-by:
-
Eray Orçunus authored
Later IdeaPads report various things in last 8 bits of _CFG, at least 5 of them represent supported on-screen-displays. Add those bit numbers to the enum, and use CFG_OSD_ as prefix of their names. Also expose the values of these bits to debugfs, since they can be useful. Signed-off-by:
Eray Orçunus <erayorcunus@gmail.com> Acked-by:
Ike Panhc <ike.pan@canonical.com> Link: https://lore.kernel.org/r/20221029120311.11152-5-erayorcunus@gmail.comReviewed-by:
-
Eray Orçunus authored
Last 8 bit of _CFG started being used in later IdeaPads, thus 30th bit doesn't always show whether device supports touchpad or touchpad switch. Remove checking bit 30 of _CFG, so older IdeaPads like S10-3 can switch touchpad again via touchpad attribute. This reverts commit b3ed1b7f ("platform/x86: ideapad-laptop: check for touchpad support in _CFG"). Signed-off-by:
-
Armin Wolf authored
On some systems (like the Dell Inspiron 3505), the acpi operation region holding the ePPID string is two bytes too short, causing acpi functions like ToString() to omit the last two bytes. This does not happen on Windows, supposedly due to their implementation of ToString() ignoring buffer boundaries. Inform users if the ePPID length differs from the Dell specification so they can complain to Dell to fix their BIOS. Tested on a Dell Inspiron 3505. Signed-off-by:
Armin Wolf <W_Armin@gmx.de> Link: https://lore.kernel.org/r/20221102212336.380257-2-W_Armin@gmx.deReviewed-by:
-
Armin Wolf authored
When the DDV interface returns a buffer, it actually returns a acpi buffer containing an integer (buffer size) and another acpi buffer (buffer content). The size of the buffer may be smaller than the size of the buffer content, which is perfectly valid and should not be treated as an error. Also use the buffer size instead of the buffer content size when accessing the buffer to prevent accessing bogus data. Tested on a Dell Inspiron 3505. Signed-off-by:
-
chen zhang authored
Fix spelling typo in comments. Reported-by:
k2ci <kernel-bot@kylinos.cn> Signed-off-by:
chen zhang <chenzhang@kylinos.cn> Acked-by:
Randy Dunlap <rdunlap@infradead.org> Link: https://lore.kernel.org/r/20221103013313.13278-1-chenzhang@kylinos.cnSigned-off-by:
-
Barnabás Pőcze authored
There is a function, `strstarts()`, in linux/string.h to check if a string is prefix of another. So remove the custom version from the driver. Signed-off-by:
Barnabás Pőcze <pobrn@protonmail.com> Link: https://lore.kernel.org/r/20221021180007.55535-1-pobrn@protonmail.comReviewed-by:
-
Jorge Lopez authored
The purpose of this patch is to provide a central location where all HP related drivers are found. HP drivers will recide under drivers/platform/x86/hp directory. Introduce changes to Kconfig file to list all HP driver under "HP X86 Platform Specific Device Drivers" menu option. Additional changes include update MAINTAINERS file to indicate hp related drivers new path. Signed-off-by:
Jorge Lopez <jorge.lopez2@hp.com> Link: https://lore.kernel.org/r/20221020201033.12790-2-jorge.lopez2@hp.comReviewed-by:
-
Jilin Yuan authored
Delete the redundant word 'to'. Signed-off-by:
Jilin Yuan <yuanjilin@cdjrlc.com> Link: https://lore.kernel.org/r/20221019125355.50674-1-yuanjilin@cdjrlc.comSigned-off-by:
-
Liming Sun authored
BlueField-3 uses the same control registers in tmfifo access but at different addresses. This commit replaces the offset reference with pointers, and set up these pointers in the probe functions accordingly. Signed-off-by:
Liming Sun <limings@nvidia.com> Reviewed-by:
David Thompson <davthompson@nvidia.com> Reviewed-by:
Vadim Pasternak <vadimp@nvidia.com> Link: https://lore.kernel.org/r/20221018133303.243920-1-limings@nvidia.comReviewed-by:
-
Hans de Goede authored
Thinklight has only two values, on/off so it's reasonable for max_brightness to be 0 and 1 as if you write anything between 0 and 255 it will be 255 anyway so there's no point for it to be 255. This may look like it is a userspace API change, but writes with a value larget then the new max_brightness will still be accepted, these will be silently clamped to the new max_brightness by led_set_brightness_nosleep(). So no userspace API problems are expected. Reported-by:
Michał Szczepaniak <m.szczepaniak.000@gmail.com> Link: https://lore.kernel.org/platform-driver-x86/55400326-e64f-5444-94e5-22b8214d00b6@gmail.com/Signed-off-by:
-
Barnabás Pőcze authored
The `huawei_wmi::idev` array is not actually used by the driver, so remove it. The piece of code that - I believe - was supposed to fill the array is flawed, it did not actually set any of the values inside the array. This was most likely masked by the fact that the input devices are devm managed and that the only function that needs a reference to the input devices is `huawei_wmi_input_notify()`, however, that does not access the appropriate input device via the `huawei_wmi` object. Signed-off-by:
-
Barnabás Pőcze authored
Previously, `huawei_wmi_input_setup()` returned the result of logical or-ing the return values of two functions that return negative errno-style error codes and one that returns `acpi_status`. If this returned value was non-zero, then it was propagated from the platform driver's probe function. That function should return a negative errno-style error code, so the result of the logical or that `huawei_wmi_input_setup()` returned was not appropriate. Fix that by checking each function separately and returning the error code unmodified. Fixes: 1ac9abeb ("platform/x86: huawei-wmi: Move to platform driver") Signed-off-by:
-
Barnabás Pőcze authored
Use `sizeof()` and `ARRAY_SIZE()` instead of hard-coding buffer sizes and indices. Signed-off-by:
-
Armin Wolf authored
The dell-wmi-ddv driver adds support for reading the current temperature and ePPID of ACPI batteries on supported Dell machines. Since the WMI interface used by this driver does not do any input validation and thus cannot be used for probing, the driver depends on the ACPI battery extension machanism to discover batteries. The driver also supports a debugfs interface for retrieving buffers containing fan and thermal sensor information. Since the meaing of the content of those buffers is currently unknown, the interface is meant for reverse-engineering and will likely be replaced with an hwmon interface once the meaning has been understood. The driver was tested on a Dell Inspiron 3505. Signed-off-by:
Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://lore.kernel.org/r/20220927204521.601887-3-W_Armin@gmx.deReviewed-by:
-
Armin Wolf authored
Right now, is impossible for battery hook callbacks to access instance-specific data, forcing most drivers to provide some sort of global state. This however is difficult for drivers which can be instantiated multiple times and/or are hotplug-capable. Pass a pointer to the battery hook to those callbacks for usage with container_of(). Signed-off-by:
Rafael J. Wysocki <rafael.j.wysocki@intel.com> Link: https://lore.kernel.org/r/20220927204521.601887-2-W_Armin@gmx.deReviewed-by:
-
Muhammad Usama Anjum authored
The out structure should be passed by reference instead of passing by value. This saves the extra copy of the structure. Signed-off-by:
Muhammad Usama Anjum <usama.anjum@collabora.com> Link: https://lore.kernel.org/r/20221004081019.619193-1-usama.anjum@collabora.comReviewed-by:
-
Hans de Goede authored
Add module parameters to allow setting the hw_rfkill_switch and set_fn_lock_led feature flags for testing these on laptops which are not on the DMI-id based allow lists for these 2 flags. Signed-off-by:
-
Arnav Rawat authored
Commit 3ae86d2d ("platform/x86: ideapad-laptop: Fix Legion 5 Fn lock LED") uses the WMI event-id for the fn-lock event on some Legion 5 laptops to manually toggle the fn-lock LED because the EC does not do it itself. However, the same WMI ID is also sent on some Yoga laptops. Here, setting the fn-lock state is not valid behavior, and causes the EC to spam interrupts until the laptop is rebooted. Add a set_fn_lock_led_list[] DMI-id list and only enable the workaround to manually set the LED on models on this list. Link: https://bugzilla.kernel.org/show_bug.cgi?id=212671 Cc: Meng Dong <whenov@gmail.com> Signed-off-by:
Arnav Rawat <arnavr3@illinois.edu> Link: https://lore.kernel.org/r/12093851.O9o76ZdvQC@fedora [hdegoede@redhat.com: Check DMI-id list only once and store the result] Signed-off-by:
-
Kai-Heng Feng authored
Sometimes hp-wmi driver complains on system resume: [ 483.116451] hp_wmi: Unknown event_id - 33 - 0x0 According to HP it's a feature called "HP Smart Experience App" and it's safe to be ignored. Signed-off-by:
Kai-Heng Feng <kai.heng.feng@canonical.com> Link: https://lore.kernel.org/r/20221114073842.205392-1-kai.heng.feng@canonical.comReviewed-by:
-
Maximilian Luz authored
Add device nodes to enable support for battery and charger status, the ACPI platform profile, as well as internal HID devices (including touchpad and keyboard) on the Surface Laptop 5. Signed-off-by:
Maximilian Luz <luzmaximilian@gmail.com> Link: https://lore.kernel.org/r/20221115231440.1338142-1-luzmaximilian@gmail.comSigned-off-by:
-
- 15 Nov, 2022 8 commits
-
-
Maximilian Luz authored
Add device nodes to enable support for battery and charger status, the ACPI platform profile, as well as internal and type-cover HID devices (including sensors, touchpad, keyboard, and other miscellaneous devices) on the Surface Pro 9. This does not include support for a tablet-mode switch yet, as that is now handled via the POS subsystem (unlike the Surface Pro 8, where it is handled via the KIP subsystem) and therefore needs further changes. While we're at it, also add the missing comment for the Surface Pro 8. Signed-off-by:
-
Maximilian Luz authored
Currently, we check any received packet whether we have already seen it previously, regardless of the packet type (sequenced / unsequenced). We do this by checking the sequence number. This assumes that sequence numbers are valid for both sequenced and unsequenced packets. However, this assumption appears to be incorrect. On some devices, the sequence number field of unsequenced packets (in particular HID input events on the Surface Pro 9) is always zero. As a result, the current retransmission check kicks in and discards all but the first unsequenced packet, breaking (among other things) keyboard and touchpad input. Note that we have, so far, only seen packets being retransmitted in sequenced communication. In particular, this happens when there is an ACK timeout, causing the EC (or us) to re-send the packet waiting for an ACK. Arguably, retransmission / duplication of unsequenced packets should not be an issue as there is no logical condition (such as an ACK timeout) to determine when a packet should be sent again. Therefore, remove the retransmission check for unsequenced packets entirely to resolve the issue. Fixes: c167b9c7 ("platform/surface: Add Surface Aggregator subsystem") Signed-off-by:
-
Hans de Goede authored
Like the Acer Switch 10 (SW5-012) and Acer Switch 10 (S1003) models the Acer Switch V 10 (SW5-017) supports reporting SW_TABLET_MODE through acer-wmi. Add a DMI quirk for the SW5-017 setting force_caps to ACER_CAP_KBD_DOCK (these devices have no other acer-wmi based functionality). Cc: Rudolf Polzer <rpolzer@google.com> Signed-off-by:
-
Xiongfeng Wang authored
pci_get_device() will increase the reference count for the returned pci_dev. We need to use pci_dev_put() to decrease the reference count before asus_wmi_set_xusb2pr() returns. Signed-off-by:
Xiongfeng Wang <wangxiongfeng2@huawei.com> Link: https://lore.kernel.org/r/20221111100752.134311-1-wangxiongfeng2@huawei.comReviewed-by:
-
Roger Pau Monné authored
The current logic in the Intel PMC driver will forcefully attach it when detecting any CPU on the intel_pmc_core_platform_ids array, even if the matching ACPI device is not present. There's no checking in pmc_core_probe() to assert that the PMC device is present, and hence on virtualized environments the PMC device probes successfully, even if the underlying registers are not present. Before commit 21ae4357 ("platform/x86: intel_pmc_core: Substitute PCI with CPUID enumeration") the driver would check for the presence of a specific PCI device, and that prevented the driver from attaching when running virtualized. Fix by only forcefully attaching the PMC device when not running virtualized. Note that virtualized platforms can still get the device to load if the appropriate ACPI device is present on the tables provided to the VM. Make an exception for the Xen initial domain, which does have full hardware access, and hence can attach to the PMC if present. Fixes: 21ae4357 ("platform/x86: intel_pmc_core: Substitute PCI with CPUID enumeration") Signed-off-by:
Roger Pau Monné <roger.pau@citrix.com> Acked-by:
David E. Box <david.e.box@linux.intel.com> Reviewed-by:
-
Lennard Gäher authored
Previously, the s2idle quirk was only active for the 21A0 machine type of the P14s Gen2a product. This also enables it for the second 21A1 type, thus reducing wake-up times from s2idle. Signed-off-by:
Lennard Gäher <gaeher@mpi-sws.org> Suggested-by:
Mario Limonciello <mario.limonciello@amd.com> Reviewed-by:
-
Shyam Sundar S K authored
Add new a new ACPI ID AMDI0009 used by upcoming AMD platform to the pmc supported list of devices. Cc: stable@vger.kernel.org # 6.0 Signed-off-by:
Shyam Sundar S K <Shyam-sundar.S-k@amd.com> Reviewed-by:
-
Mario Limonciello authored
commit b37fe34c ("platform/x86/amd: pmc: remove CONFIG_DEBUG_FS checks") removed most CONFIG_DEBUG_FS checks, but there were some left that were reported to cause compile test failures. Remove the remaining checks, and also the unnecessary CONFIG_SUSPEND used in the same place. Reported-by: liyupeng@zbhlos.com Fixes: b37fe34c ("platform/x86/amd: pmc: remove CONFIG_DEBUG_FS checks") Signed-off-by:
-
- 07 Nov, 2022 9 commits
-
-
Andy Shevchenko authored
We have accessing P2SB from a very few places for quite known hardware. When a new SoC appears in intel-family.h it's not obvious that it needs to be added to p2sb.c as well. Instead, provide default BDF and refactor p2sb_get_devfn() to always succeed. If in the future we would need to exclude something, we may add a list of unsupported IDs. Without this change the iTCO on Intel Comet Lake SoCs became unavailable: i801_smbus 0000:00:1f.4: failed to create iTCO device Fixes: 5c7b9167 ("i2c: i801: convert to use common P2SB accessor") Reported-and-tested-by:
Jarkko Nikula <jarkko.nikula@linux.intel.com> Signed-off-by:
-
Ivan Hu authored
Add INTC1076 (JasonLake), INTC1077 (MeteorLake) and INTC1078 (RaptorLake) devices IDs. Signed-off-by:
Ivan Hu <ivan.hu@canonical.com> Link: https://lore.kernel.org/r/20221102020548.5225-1-ivan.hu@canonical.comReviewed-by:
-
David E. Box authored
On Sapphire Rapids, due to a hardware issue affecting the PUNIT telemetry region, reads that are not done in QWORD quantities and alignment may return incorrect data. Use a custom 64-bit copy for this region. Signed-off-by:
-
Jorge Lopez authored
After upgrading BIOS to U82 01.02.01 Rev.A, the console is flooded strange char "^@" which printed out every second and makes login nearly impossible. Also the below messages were shown both in console and journal/dmesg every second: usb 1-3: Device not responding to setup address. usb 1-3: device not accepting address 4, error -71 usb 1-3: device descriptor read/all, error -71 usb usb1-port3: unable to enumerate USB device Wifi is soft blocked by checking rfkill. When unblocked manually, after few seconds it would be soft blocked again. So I was suspecting something triggered rfkill to soft block wifi. At the end it was fixed by removing hp_wmi module. The root cause is the way hp-wmi driver handles command 1B on post-2009 BIOS. In pre-2009 BIOS, command 1Bh return 0x4 to indicate that BIOS no longer controls the power for the wireless devices. Signed-off-by:
-
Hans de Goede authored
Add touchscreen info for the RCA Cambio W101 v2 2-in-1. Link: https://github.com/onitake/gsl-firmware/discussions/193Signed-off-by:
-
Manyi Li authored
Ideapads for "Lenovo Yoga 3 Pro 1370" and "ZhaoYang K4e-IML" do not use EC to switch touchpad. Reading VPCCMD_R_TOUCHPAD will return zero thus touchpad may be blocked unexpectedly. Signed-off-by:
Manyi Li <limanyi@uniontech.com> Link: https://lore.kernel.org/r/20221018095323.14591-1-limanyi@uniontech.comReviewed-by:
-
Hans de Goede authored
The Dell G15 5515 has the WMI interface (and WMI call returns) expected by the nvidia-wmi-ec-backlight interface. But the backlight class device registered by the nvidia-wmi-ec-backlight driver does not actually work. The amdgpu_bl0 native GPU backlight class device does actually work, add a backlight=native DMI quirk for this. Reported-by:
Iris <pawel.js@protonmail.com> Reviewed-by:
Daniel Dadap <ddadap@nvidia.com> Signed-off-by:
-
Hans de Goede authored
Testing has shown that there are quite a few laptop models which rely on native backlight control and which do not support ACPI video bus backlight control, causing __acpi_video_get_backlight_type() to return vendor. Known Windows laptop models affected by this are: Acer Aspire 1640 HP Compaq nc6120 IBM ThinkPad X40 System76 Starling Star1 and the following MacBook models are affected too: Apple MacBook 2.1 Apple MacBook 4.1 Apple MacBook Pro 7.1 the list of affected Windows laptop models is likely just the top of the iceberg. So for now lets undo the change to not register native backlight class devices when __acpi_video_get_backlight_type() != native. Since as part of the backlight-detect refactor the detection code now relies on the GPU drivers calling acpi_video_backlight_use_native() to learn that native backlight support is available we cannot just remove the acpi_video_backlight_use_native() calls from the GPU drivers. Instead modify acpi_video_backlight_use_native() to always return true for now. This is meant as a temporary work-around, which will be removed again when the heuristics from __acpi_video_get_backlight_type() have been improved so that they will return native on affected models. Reported-by:
Matthew Garrett <mjg59@srcf.ucam.org> Reported-by:
John Warriner <taijitu@cox.net> Reported-by:
Scott Ostrander <sos12_3@hotmail.com> Reported-by:
Matthias Rampke <matthias.rampke@googlemail.com> Reported-by:
Milan Hodoscek <hmilan@gmail.com> Signed-off-by:
-
Hans de Goede authored
2 improvements for the Chromebook handling in acpi_video_get_backlight_type(): 1. Also check for the "GOOG000C" ACPI HID used on some models 2. Move the Chromebook check to above the ACPI-video check normally Chromebooks don't have ACPI video backlight support, but when flashed with upstream coreboot builds they may have ACPI video backlight support, but native should still be used/preferred then. Suggested-by:
Mr. Chromebox <mrchromebox@gmail.com> Signed-off-by:
-
- 24 Oct, 2022 2 commits
-
-
Dmitry Osipenko authored
Chromebooks don't have backlight in ACPI table, they suppose to use native backlight in this case. Check presence of the CrOS embedded controller ACPI device and prefer the native backlight if EC found. Suggested-by:
Dmitry Osipenko <dmitry.osipenko@collabora.com> Reviewed-by:
-
Gayatri Kammela authored
Add Raptor Lake client parts (both RPL and RPL_S) support to pmc core driver. Raptor Lake client parts reuse all the Alder Lake PCH IPs. Cc: Srinivas Pandruvada <srinivas.pandruvada@intel.com> Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Cc: David Box <david.e.box@intel.com> Acked-by:
Rajneesh Bhardwaj <irenic.rajneesh@gmail.com> Signed-off-by:
Gayatri Kammela <gayatri.kammela@linux.intel.com> Link: https://lore.kernel.org/r/20220912233307.409954-2-gayatri.kammela@linux.intel.comReviewed-by:
-
