- 12 Aug, 2021 14 commits
-
-
Luke D. Jones authored
In Windows the ASUS Armory Crate program can enable or disable the dGPU via a WMI call. This functions much the same as various Linux methods in software where the dGPU is removed from the device tree. However the WMI call saves the state of dGPU (enabled or not) and this then changes the dGPU visibility in Linux with no way for Linux users to re-enable it. We expose the WMI method so users can see and change the dGPU ACPI state. Signed-off-by:
Luke D. Jones <luke@ljones.dev> Link: https://lore.kernel.org/r/20210807023656.25020-3-luke@ljones.devReviewed-by:
Hans de Goede <hdegoede@redhat.com> Signed-off-by:
-
Luke D. Jones authored
Some ASUS ROG laptops have the ability to drive the display panel a higher rate to eliminate or reduce ghosting. Signed-off-by:
-
Hans de Goede authored
The Asus TP200s / E205SA 360 degree hinges 2-in-1 supports reporting SW_TABLET_MODE info through the ASUS_WMI_DEVID_LID_FLIP WMI device-id. Add a quirk to enable this. BugLink: https://gitlab.freedesktop.org/libinput/libinput/-/issues/639Signed-off-by:
-
Hans de Goede authored
Unfortunately we have been unable to find a reliable way to detect if and how SW_TABLET_MODE reporting is supported, so we are relying on DMI quirks for this. Add a module-option to specify the SW_TABLET_MODE method so that this can be easily tested without needing to rebuild the kernel. BugLink: https://gitlab.freedesktop.org/libinput/libinput/-/issues/639Signed-off-by:
-
Chris Blake authored
This adds platform support for the Cisco Meraki MX100 (Tinkerbell) network appliance. This sets up the network LEDs and Reset button. Depends-on: ef0eea5b ("mfd: lpc_ich: Enable GPIO driver for DH89xxCC") Co-developed-by:
Christian Lamparter <chunkeey@gmail.com> Signed-off-by:
Chris Blake <chrisrblake93@gmail.com> Reviewed-by:
Andy Shevchenko <andy.shevchenko@gmail.com> Link: https://lore.kernel.org/r/20210810004021.2538308-1-chrisrblake93@gmail.comReviewed-by:
-
Andy Shevchenko authored
The 'objs' is for user space tools, for the kernel modules we should use 'y'. Signed-off-by:
Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by:
Daniel Scally <djrscally@gmail.com> Link: https://lore.kernel.org/r/20210806154951.4564-1-andriy.shevchenko@linux.intel.comSigned-off-by:
-
Andy Shevchenko authored
The 'objs' is for user space tools, for the kernel modules we should use 'y'. Signed-off-by:
-
Andy Shevchenko authored
The 'objs' is for user space tools, for the kernel modules we should use 'y'. Signed-off-by:
-
Andy Shevchenko authored
ACPI core in conjunction with platform driver core provides an infrastructure to enumerate ACPI devices. Use it in order to remove a lot of boilerplate code. Signed-off-by:
Pali Rohár <pali@kernel.org> Tested-by:
-
Andy Shevchenko authored
The 'objs' is for user space tools, for the kernel modules we should use 'y'. Signed-off-by:
Maximilian Luz <luzmaximilian@gmail.com> Link: https://lore.kernel.org/r/20210803192524.67031-1-andriy.shevchenko@linux.intel.comSigned-off-by:
-
Andy Shevchenko authored
ACPI provides a generic helper to get I²C Serial Bus resources. Use it instead of open coded variant. Signed-off-by:
-
Sebastian Andrzej Siewior authored
The functions get_online_cpus() and put_online_cpus() have been deprecated during the CPU hotplug rework. They map directly to cpus_read_lock() and cpus_read_unlock(). Replace deprecated CPU-hotplug functions with the official version. The behavior remains unchanged. Cc: Stuart Hayes <stuart.w.hayes@gmail.com> Cc: Hans de Goede <hdegoede@redhat.com> Cc: Mark Gross <mgross@linux.intel.com> Cc: platform-driver-x86@vger.kernel.org Signed-off-by:
Sebastian Andrzej Siewior <bigeasy@linutronix.de> Link: https://lore.kernel.org/r/20210803141621.780504-18-bigeasy@linutronix.deSigned-off-by:
-
Hans de Goede authored
dell-smbios is depended on by dell-laptop and that has this same table + some extra entries for chassis-type 30, 31 and 32. Since dell-laptop will already auto-load based on the DMI table in there (which also is more complete) and since dell-laptop will then bring in the dell-smbios module, the only scenario I can think of where this DMI table inside dell-smbios-smm.c is useful is if users have the dell-laptop module disabled and they want to use the sysfs interface offered by dell-smbios-smm.c. But that is such a corner case, even requiring a custom kernel build, that it does not weigh up against having this duplicate table, which as the current state already shows can only grow stale. Users who do hit this corner-case can always explicitly modprobe / insmod the module. Cc: Mario Limonciello <mario.limonciello@outlook.com> Signed-off-by:
-
Srinivas Pandruvada authored
When numa is used to map CPU to PCI device, the optimized path to read from cached data is not working and still calls _isst_if_get_pci_dev(). The reason is that when caching the mapping, numa information is not available as it is read later. So move the assignment of isst_cpu_info[cpu].numa_node before calling _isst_if_get_pci_dev(). Fixes: aa2ddd24 ("platform/x86: ISST: Use numa node id for cpu pci dev mapping") Signed-off-by:
Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Link: https://lore.kernel.org/r/20210727165052.427238-1-srinivas.pandruvada@linux.intel.comSigned-off-by:
-
- 06 Aug, 2021 3 commits
-
-
David E. Box authored
Move all Intel Platform Monitoring Technology drivers to drivers/platform/x86/intel/pmt. Signed-off-by:
David E. Box <david.e.box@linux.intel.com> Reviewed-by:
-
Hans de Goede authored
The gpiod_lookup_table.table passed to gpiod_add_lookup_table() must be terminated with an empty entry, add this. Note we have likely been getting away with this not being present because the GPIO lookup code first matches on the dev_id, causing most lookups to skip checking the table and the lookups which do check the table will find a matching entry before reaching the end. With that said, terminating these tables properly still is obviously the correct thing to do. Fixes: f8eb0235 ("x86: pcengines apuv2 gpio/leds/keys platform driver") Signed-off-by:
-
Hans de Goede authored
360 degree hinges devices with dual KIOX010A + KIOX020A accelerometers always have both a KIOX010A and a KIOX020A ACPI device (one for each accel). Theoretical some vendor may re-use some DSDT for a non-convertible stripping out just the KIOX020A ACPI device from the DSDT. Check that both ACPI devices are present to make the check more robust. Fixes: 153cca9c ("platform/x86: Add and use a dual_accel_detect() helper") Signed-off-by:
-
- 29 Jul, 2021 1 commit
-
-
Hans de Goede authored
Various 360 degree hinges (yoga) style 2-in-1 devices use 2 accelerometers to allow the OS to determine the angle between the display and the base of the device. On Windows these are read by a special HingeAngleService process which calls undocumented ACPI methods, to let the firmware know if the 2-in-1 is in tablet- or laptop-mode. The firmware may use this to disable the kbd and touchpad to avoid spurious input in tablet-mode as well as to report SW_TABLET_MODE info to the OS. Since Linux does not call these undocumented methods, the SW_TABLET_MODE info reported by various pdx86 drivers is incorrect on these devices. Before this commit the intel-hid and thinkpad_acpi code already had 2 hardcoded checks for ACPI hardware-ids of dual-accel sensors to avoid reporting broken info. And now we also have a bug-report about the same problem in the intel-vbtn code. Since there are at least 3 different ACPI hardware-ids in play, add a new dual_accel_detect() helper which checks for all 3, rather then adding different hardware-ids to the drivers as bug-reports trickle in. Having shared code which checks all known hardware-ids is esp. important for the intel-hid and intel-vbtn drivers as these are generic drivers which are used on a lot of devices. The BOSC0200 hardware-id requires special handling, because often it is used for a single-accelerometer setup. Only in a few cases it refers to a dual-accel setup, in which case there will be 2 I2cSerialBus resources in the device's resource-list, so the helper checks for this. BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=209011Reported-and-tested-by:
Julius Lehmann <julius@devpi.de> Signed-off-by:
-
- 28 Jul, 2021 2 commits
-
-
Thomas Weißschuh authored
Reported as working here: https://github.com/t-8ch/linux-gigabyte-wmi-driver/issues/1#issuecomment-879398883Signed-off-by:
Thomas Weißschuh <linux@weissschuh.net> Link: https://lore.kernel.org/r/20210726153630.65213-1-linux@weissschuh.netSigned-off-by:
-
Ping Bao authored
Alder Lake has a new ACPI ID for Intel HID event filter device. Signed-off-by:
Ping Bao <ping.a.bao@intel.com> Link: https://lore.kernel.org/r/20210721225615.20575-1-ping.a.bao@intel.comSigned-off-by:
-
- 17 Jul, 2021 4 commits
-
-
Hans de Goede authored
Fix 2 possible memleaks on error-exits from tlmi_analyze(): 1. If the kzalloc of pwd_power fails, then not only free the atributes, but also the allocated pwd_admin struct. 2. Freeing the attributes should also free the possible_values strings. Signed-off-by:
-
Hans de Goede authored
tlmi_sysfs_init() calls tlmi_release_attr() on errors which calls kobject_put() for attributes created by tlmi_analyze(), but if we bail early because of an error, then this means that some of the kobjects will not have been initialized yet; and we should thus not call kobject_put() on them. Switch from using kobject_init_and_add() inside tlmi_sysfs_init() to initializing all the created kobjects directly in tlmi_analyze() and only adding them from tlmi_sysfs_init(). This way all kobjects will always be initialized when tlmi_release_attr() gets called. Signed-off-by:
-
Mark Pearson authored
Move the pending_reboot node under attributes dir where it should live, as documented in: Documentation/ABI/testing/sysfs-class-firmware-attributes. Also move the create / remove code to be together with the other code populating / cleaning the attributes sysfs dir. In the removal path this is necessary so that the remove is done before the kset_unregister(tlmi_priv.attribute_kset) call. Signed-off-by:
Mark Pearson <markpearson@lenovo.com> Co-developed-by:
-
Shyam Sundar S K authored
It was reported that on i386 config ------ on i386: ld: drivers/platform/x86/amd-pmc.o: in function `s0ix_stats_show': amd-pmc.c:(.text+0x100): undefined reference to `__udivdi3' ------- The reason for this is that 64-bit integer division is not supported on 32-bit architecture. Use do_div macro to fix this. Fixes: b9a4fa69 ("platform/x86: amd-pmc: Add support for logging s0ix counters") Reported-by:
Randy Dunlap <rdunlap@infradead.org> Signed-off-by:
Shyam Sundar S K <Shyam-sundar.S-k@amd.com> Reviewed-by: Randy Dunlap <rdunlap@infradead.org> # and build-tested Link: https://lore.kernel.org/r/20210716153802.2929670-1-Shyam-sundar.S-k@amd.comSigned-off-by:
-
- 15 Jul, 2021 1 commit
-
-
Yang Yingliang authored
Add the missing unlock before return from function amd_pmc_send_cmd() in the error handling case. Fixes: 95e1b60f ("platform/x86: amd-pmc: Fix command completion code") Reported-by:
Hulk Robot <hulkci@huawei.com> Signed-off-by:
Yang Yingliang <yangyingliang@huawei.com> Link: https://lore.kernel.org/r/20210715074327.1966083-1-yangyingliang@huawei.comSigned-off-by:
-
- 14 Jul, 2021 10 commits
-
-
Alex Hung authored
This driver is no longer specific to HP laptops so "hp" in the error message is no longer applicable. Signed-off-by:
Alex Hung <alex.hung@canonical.com> Link: https://lore.kernel.org/r/20210710190810.313104-1-alex.hung@canonical.comSigned-off-by:
-
Mario Limonciello authored
Right now the driver will still return success even if the OS_HINT command failed to send to the SMU. In the rare event of a failure, the suspend should really be aborted here so that relevant logs can may be captured. Signed-off-by:
Mario Limonciello <mario.limonciello@amd.com> Acked-by:
-
Shyam Sundar S K authored
The upcoming PMC controller would have a newer acpi id, add that to the supported acpid device list. Signed-off-by:
-
Shyam Sundar S K authored
Some newer BIOSes have added another ACPI ID for the uPEP device. SMU statistics behave identically on this device. Signed-off-by:
-
Shyam Sundar S K authored
Even the FCH SSC registers provides certain level of information about the s0ix entry and exit times which comes handy when the SMU fails to report the statistics via the mailbox communication. This information is captured via a new debugfs file "s0ix_stats". A non-zero entry in this counters would mean that the system entered the s0ix state. If s0ix entry time and exit time don't change during suspend to idle, the silicon has not entered the deepest state. Signed-off-by:
-
Shyam Sundar S K authored
SMU provides a way to dump the s0ix debug statistics in the form of a metrics table via a of set special mailbox commands. Add support to the driver which can send these commands to SMU and expose the information received via debugfs. The information contains the s0ix entry/exit, active time of each IP block etc. As a side note, SMU subsystem logging is not supported on Picasso based SoC's. Signed-off-by:
-
Shyam Sundar S K authored
Currently amd_pmc_dump_registers() routine is being called at multiple places. The best to call it is after command submission to SMU. Signed-off-by:
-
Shyam Sundar S K authored
It was lately understood that the current mechanism available in the driver to get SMU firmware info works only on internal SMU builds and there is a separate way to get all the SMU logging counters (addressed in the next patch). Hence remove all the smu info shown via debugfs as it is no more useful. Fixes: 156ec473 ("platform/x86: amd-pmc: Add AMD platform support for S2Idle") Signed-off-by:
-
Shyam Sundar S K authored
The protocol to submit a job request to SMU is to wait for AMD_PMC_REGISTER_RESPONSE to return 1,meaning SMU is ready to take requests. PMC driver has to make sure that the response code is always AMD_PMC_RESULT_OK before making any command submissions. When we submit a message to SMU, we have to wait until it processes the request. Adding a read_poll_timeout() check as this was missing in the existing code. Also, add a mutex to protect amd_pmc_send_cmd() calls to SMU. Fixes: 156ec473 ("platform/x86: amd-pmc: Add AMD platform support for S2Idle") Signed-off-by:
Raul E Rangel <rrangel@chromium.org> Reviewed-by:
-
Mark Pearson authored
The Think-lmi driver was missing pending_reboot support as it wasn't available from the BIOS. Turns out this is really useful to have from user space so implementing from a purely SW point of view. Thanks to Mario Limonciello for guidance on how fwupd would use this. Suggested-by:
-
- 11 Jul, 2021 5 commits
-
-
Linus Torvalds authored
-
Hugh Dickins authored
I know nothing about zone_device pages and !device_private pages; but if try_to_migrate_one() will do nothing for them, then it's better that try_to_migrate() filter them first, than trawl through all their vmas. Signed-off-by:
Hugh Dickins <hughd@google.com> Reviewed-by:
Shakeel Butt <shakeelb@google.com> Reviewed-by:
Alistair Popple <apopple@nvidia.com> Link: https://lore.kernel.org/lkml/1241d356-8ec9-f47b-a5ec-9b2bf66d242@google.com/ Cc: Andrew Morton <akpm@linux-foundation.org> Cc: Jason Gunthorpe <jgg@nvidia.com> Cc: Ralph Campbell <rcampbell@nvidia.com> Cc: Christoph Hellwig <hch@lst.de> Cc: Yang Shi <shy828301@gmail.com> Cc: Kirill A. Shutemov <kirill.shutemov@linux.intel.com> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org>
-
Hugh Dickins authored
In the unlikely race case that page_mlock_one() finds VM_LOCKED has been cleared by the time it got page table lock, page_vma_mapped_walk_done() must be called before returning, either explicitly, or by a final call to page_vma_mapped_walk() - otherwise the page table remains locked. Fixes: cd62734c ("mm/rmap: split try_to_munlock from try_to_unmap") Signed-off-by:
kernel test robot <oliver.sang@intel.com> Link: https://lore.kernel.org/lkml/20210711151446.GB4070@xsang-OptiPlex-9020/ Link: https://lore.kernel.org/lkml/f71f8523-cba7-3342-40a7-114abc5d1f51@google.com/ Cc: Andrew Morton <akpm@linux-foundation.org> Cc: Jason Gunthorpe <jgg@nvidia.com> Cc: Ralph Campbell <rcampbell@nvidia.com> Cc: Christoph Hellwig <hch@lst.de> Cc: Yang Shi <shy828301@gmail.com> Cc: Kirill A. Shutemov <kirill.shutemov@linux.intel.com> Signed-off-by:
-
Hugh Dickins authored
The kernel recovers in due course from missing Mlocked pages: but there was no point in calling page_mlock() (formerly known as try_to_munlock()) on a THP, because nothing got done even when it was found to be mapped in another VM_LOCKED vma. It's true that we need to be careful: Mlocked accounting of pte-mapped THPs is too difficult (so consistently avoided); but Mlocked accounting of only-pmd-mapped THPs is supposed to work, even when multiple mappings are mlocked and munlocked or munmapped. Refine the tests. There is already a VM_BUG_ON_PAGE(PageDoubleMap) in page_mlock(), so page_mlock_one() does not even have to worry about that complication. (I said the kernel recovers: but would page reclaim be likely to split THP before rediscovering that it's VM_LOCKED? I've not followed that up) Fixes: 9a73f61b ("thp, mlock: do not mlock PTE-mapped file huge pages") Signed-off-by:
Kirill A. Shutemov <kirill.shutemov@linux.intel.com> Link: https://lore.kernel.org/lkml/cfa154c-d595-406-eb7d-eb9df730f944@google.com/ Cc: Andrew Morton <akpm@linux-foundation.org> Cc: Alistair Popple <apopple@nvidia.com> Cc: Jason Gunthorpe <jgg@nvidia.com> Cc: Ralph Campbell <rcampbell@nvidia.com> Cc: Christoph Hellwig <hch@lst.de> Cc: Yang Shi <shy828301@gmail.com> Signed-off-by:
-
Hugh Dickins authored
Parallel developments in mm/rmap.c have left behind some out-of-date comments: try_to_migrate_one() also accepts TTU_SYNC (already commented in try_to_migrate() itself), and try_to_migrate() returns nothing at all. TTU_SPLIT_FREEZE has just been deleted, so reword the comment about it in mm/huge_memory.c; and TTU_IGNORE_ACCESS was removed in 5.11, so delete the "recently referenced" comment from try_to_unmap_one() (once upon a time the comment was near the removed codeblock, but they drifted apart). Signed-off-by:
-
