- 14 Jul, 2022 1 commit
-
-
Hans de Goede authored
Commit 3a0cf7ab ("ACPI: video: Change how we determine if brightness key-presses are handled") made acpi_video_handles_brightness_key_presses() report false when none of the ACPI Video Devices support backlight control. But it turns out that at least on a Dell Inspiron N4010 there is no ACPI backlight control, yet brightness hotkeys are still reported through the ACPI Video Bus; and since acpi_video_handles_brightness_key_presses() now returns false, brightness keypresses are now reported twice. To fix this rename the has_backlight flag to may_report_brightness_keys and also set it the first time a brightness key press event is received. Depending on the delivery of the other ACPI (WMI) event vs the ACPI Video Bus event this means that the first brightness key press might still get reported twice, but all further keypresses will be filtered as before. Note that this relies on other drivers reporting brightness key events calling acpi_video_handles_brightness_key_presses() when delivering the events (rather then once during driver probe). This is already required and documented in include/acpi/video.h: /* * Note: The value returned by acpi_video_handles_brightness_key_presses() * may change over time and should not be cached. */ Fixes: 3a0cf7ab ("ACPI: video: Change how we determine if brightness key-presses are handled") Link: https://lore.kernel.org/regressions/CALF=6jEe5G8+r1Wo0vvz4GjNQQhdkLT5p8uCHn6ZXhg4nsOWow@mail.gmail.com/Reported-and-tested-by:
Ben Greening <bgreening@gmail.com> Signed-off-by:
Hans de Goede <hdegoede@redhat.com> Acked-by:
Rafael J. Wysocki <rafael.j.wysocki@intel.com> Link: https://lore.kernel.org/r/20220713211101.85547-2-hdegoede@redhat.com
-
- 10 Jul, 2022 8 commits
-
-
Hans de Goede authored
Like the Asus T100TA the Asus T100TAF has a camera LED which is always on by default and both also use the same GPIO for the LED. Relax the DMI match for the Asus T100TA so that it also matches the T100TAF. Signed-off-by:
-
Hans de Goede authored
A recent suggested change to the IFS code has shown that the userspace API needs a bit more work, see: https://lore.kernel.org/platform-driver-x86/20220708151938.986530-1-jithu.joseph@intel.com/ Mark it as BROKEN before 5.19 ships, to give ourselves one more kernel-devel cycle to get the userspace API right. Link: https://lore.kernel.org/platform-driver-x86/20220708151938.986530-1-jithu.joseph@intel.com/ Cc: Jithu Joseph <jithu.joseph@intel.com> Cc: Ashok Raj <ashok.raj@intel.com> Cc: Tony Luck <tony.luck@intel.com> Suggested-by:
Greg KH <gregkh@linuxfoundation.org> Signed-off-by:
-
Misaka19465 authored
On laptops like ASUS TUF Gaming A15, which have hotkeys to start Armoury Crate or AURA Sync, these hotkeys are unavailable. This patch add mappings for them. Signed-off-by:
Misaka19465 <misaka19465@olddoctor.net> Link: https://lore.kernel.org/r/20220710113727.281634-1-misaka19465@olddoctor.netReviewed-by:
-
Hans de Goede authored
Commit 98f30d0e ("ACPI: power: Switch to sys-off handler API") switched the ACPI sleep code from directly setting the old global pm_power_off handler to using the new register_sys_off_handler() mechanism with a priority of SYS_OFF_PRIO_FIRMWARE. This is a problem when the old global pm_power_off handler would later be overwritten, such as done by the late_initcall(efi_shutdown_init): if (efi_poweroff_required()) pm_power_off = efi_power_off; The old global pm_power_off handler gets run with a priority of SYS_OFF_PRIO_DEFAULT which is lower then SYS_OFF_PRIO_FIRMWARE, causing acpi_power_off() to run first, changing the behavior from before the ACPI sleep code switched to the new register_sys_off_handler(). Switch the registering of efi_power_off over to register_sys_off_handler() with a priority of SYS_OFF_PRIO_FIRMWARE + 1 so that it will run before acpi_power_off() as before. Note since the new sys-off-handler code will try all handlers in priority order, there is no more need for the EFI code to store and call the original pm_power_off handler. Fixes: 98f30d0e ("ACPI: power: Switch to sys-off handler API") Cc: Dmitry Osipenko <dmitry.osipenko@collabora.com> Signed-off-by:
Ard Biesheuvel <ardb@kernel.org> Link: https://lore.kernel.org/r/20220708131412.81078-3-hdegoede@redhat.com
-
Hans de Goede authored
Commit 98f30d0e ("ACPI: power: Switch to sys-off handler API") switched the ACPI sleep code from directly setting the old global pm_power_off handler to using the new register_sys_off_handler() mechanism with a priority of SYS_OFF_PRIO_FIRMWARE. This is a problem in special cases where the old global pm_power_off handler later gets overwritten, such as the Lenovo Tab2 poweroff bugfix in x86-android-tablets. The old global pm_power_off handler gets run with a priority of SYS_OFF_PRIO_DEFAULT which is lower then SYS_OFF_PRIO_FIRMWARE, causing the troublesome ACPI poweroff (which freezes the system) to run first. Switch the registering of lenovo_yoga_tab2_830_1050_power_off over to register_sys_off_handler() with a priority of SYS_OFF_PRIO_FIRMWARE + 1 so that it will run before acpi_power_off() to fix this. Fixes: 98f30d0e ("ACPI: power: Switch to sys-off handler API") Cc: Dmitry Osipenko <dmitry.osipenko@collabora.com> Signed-off-by:
-
Pär Eriksson authored
Add support for the B660I AORUS PRO DDR4. Signed-off-by:
Pär Eriksson <parherman@gmail.com> Link: https://lore.kernel.org/r/20220705184407.14181-1-parherman@gmail.comSigned-off-by:
-
Shyam Sundar S K authored
PMC driver can be supported on a new upcoming platform. Add this information to the support list. Signed-off-by:
Shyam Sundar S K <Shyam-sundar.S-k@amd.com> Link: https://lore.kernel.org/r/20220630050324.3780654-2-Shyam-sundar.S-k@amd.comReviewed-by:
-
Shyam Sundar S K authored
New version of PMC controller will have a separate ACPI id, add that to the support list. Signed-off-by:
-
- 28 Jun, 2022 9 commits
-
-
Kai-Heng Feng authored
After system resume the hp-wmi driver may complain: [ 702.620180] hp_wmi: Unknown event_id - 23 - 0x0 According to HP it means 'Sanitization Mode' and it's harmless to just ignore the event. Cc: Jorge Lopez <jorge.lopez2@hp.com> Signed-off-by:
Kai-Heng Feng <kai.heng.feng@canonical.com> Link: https://lore.kernel.org/r/20220628123726.250062-1-kai.heng.feng@canonical.comReviewed-by:
-
Mark Pearson authored
PSC platform profile mode is only supported on Linux for AMD platforms. Some older Intel platforms (e.g T490) are advertising it's capability as Windows uses it - but on Linux we should only be using MMC profile for Intel systems. Add a check to prevent it being enabled incorrectly. Signed-off-by:
Mark Pearson <markpearson@lenovo.com> Link: https://lore.kernel.org/r/20220627181449.3537-1-markpearson@lenovo.comReviewed-by:
-
Mark Pearson authored
Currently the active mode (PSC/MMC) is stored in an enum and queried throughout the driver. Other driver changes will enumerate additional submodes that are relevant to be tracked, so instead track PSC/MMC in a single integer variable. Co-developed-by:
Mario Limonciello <mario.limonciello@amd.com> Signed-off-by:
-
Hans de Goede authored
On some Panasonic models the volume up/down/mute keypresses get reported both through the Panasonic ACPI HKEY interface as well as through the atkbd device. Filter out the atkbd scan-codes for these to avoid reporting presses twice. Note normally we would leave the filtering of these to userspace by mapping the scan-codes to KEY_UNKNOWN through /lib/udev/hwdb.d/60-keyboard.hwdb. However in this case that would cause regressions since we were filtering the Panasonic ACPI HKEY events before, so filter these in the kernel. Fixes: ed83c917 ("platform/x86: panasonic-laptop: Resolve hotkey double trigger bug") Reported-and-tested-by:
Stefan Seyfried <seife+kernel@b1-systems.com> Reported-and-tested-by:
Kenneth Chan <kenneth.t.chan@gmail.com> Signed-off-by:
Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://lore.kernel.org/r/20220624112340.10130-7-hdegoede@redhat.com
-
Hans de Goede authored
The brightness key-presses might also get reported by the ACPI video bus, check for this and in this case don't report the presses to avoid reporting 2 presses for a single key-press. Fixes: ed83c917 ("platform/x86: panasonic-laptop: Resolve hotkey double trigger bug") Reported-and-tested-by:
-
Hans de Goede authored
In hindsight blindly throwing away most of the key-press events is not a good idea. So revert commit ed83c917 ("platform/x86: panasonic-laptop: Resolve hotkey double trigger bug"). Fixes: ed83c917 ("platform/x86: panasonic-laptop: Resolve hotkey double trigger bug") Reported-and-tested-by:
-
Hans de Goede authored
Sort includes alphabetically, small cleanup patch in preparation of further changes. Fixes: ed83c917 ("platform/x86: panasonic-laptop: Resolve hotkey double trigger bug") Signed-off-by:
-
Stefan Seyfried authored
In the definition of panasonic_keymap[] the key codes are given in decimal, later checks are done with hexadecimal values, which does not help in understanding the code. Additionally use two helper variables to shorten the code and make the logic more obvious. Fixes: ed83c917 ("platform/x86: panasonic-laptop: Resolve hotkey double trigger bug") Signed-off-by:
-
Hans de Goede authored
Some systems have an ACPI video bus but not ACPI video devices with backlight capability. On these devices brightness key-presses are (logically) not reported through the ACPI video bus. Change how acpi_video_handles_brightness_key_presses() determines if brightness key-presses are handled by the ACPI video driver to avoid vendor specific drivers/platform/x86 drivers filtering out their brightness key-presses even though they are the only ones reporting these presses. Fixes: ed83c917 ("platform/x86: panasonic-laptop: Resolve hotkey double trigger bug") Reported-and-tested-by:
-
- 27 Jun, 2022 5 commits
-
-
Hans de Goede authored
The Ideapad 5 15ITL05 uses DYTC version 4 for platform-profile control. This has been tested successfully with the ideapad-laptop DYTC version 5 code; Add the Ideapad 5 15ITL05 to the ideapad_dytc_v4_allow_table[]. Fixes: 599482c5 ("platform/x86: ideapad-laptop: Add platform support for Ideapad 5 Pro 16ACH6-82L5") Link: https://bugzilla.kernel.org/show_bug.cgi?id=213297Signed-off-by:
-
Hans de Goede authored
Add an allow_v4_dytc module parameter to allow users to easily test if DYTC version 4 platform-profiles work on their laptop. Fixes: 599482c5 ("platform/x86: ideapad-laptop: Add platform support for Ideapad 5 Pro 16ACH6-82L5") Link: https://bugzilla.kernel.org/show_bug.cgi?id=213297Signed-off-by:
-
Jean Delvare authored
Unlike release_mem_region(), a call to release_resource() does not free the resource, so it has to be freed explicitly to avoid a memory leak. Signed-off-by:
Jean Delvare <jdelvare@suse.de> Fixes: 455cd867 ("platform/x86: thinkpad_acpi: Add a s2idle resume quirk for a number of laptops") Cc: Mario Limonciello <mario.limonciello@amd.com> Cc: Henrique de Moraes Holschuh <hmh@hmh.eng.br> Cc: Hans de Goede <hdegoede@redhat.com> Cc: Mark Gross <markgross@kernel.org> Reviewed-by:
-
Dan Carpenter authored
This should return PTR_ERR() instead of IS_ERR(). Also "dev->client" has been set to NULL by this point so it returns 0/success so preserve the error code earlier. Fixes: 662f2482 ("platform/mellanox: Add support for new SN2201 system") Signed-off-by:
Dan Carpenter <dan.carpenter@oracle.com> Acked-by:
Michael Shych <michaelsh@nvidia.com> Link: https://lore.kernel.org/r/YqmUGwmPK7cPolk/@kiliReviewed-by:
-
Gayatri Kammela authored
Add Alder Lake N (ADL-N) to the list of the platforms that Intel's PMC core driver supports. Alder Lake N reuses all the TigerLake PCH IPs. Cc: Srinivas Pandruvada <srinivas.pandruvada@intel.com> Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Cc: David E. Box <david.e.box@linux.intel.com> Signed-off-by:
Gayatri Kammela <gayatri.kammela@linux.intel.com> Reviewed-by:
Rajneesh Bhardwaj <irenic.rajneesh@gmail.com> Link: https://lore.kernel.org/r/20220615002751.3371730-1-gayatri.kammela@linux.intel.comReviewed-by:
-
- 12 Jun, 2022 3 commits
-
-
Duke Lee authored
The Surface Go reports Chassis Type 9 (Laptop,) so the device needs to be added to dmi_vgbs_allow_list to enable tablet mode when an attached Type Cover is folded back. BugLink: https://github.com/linux-surface/linux-surface/issues/837Signed-off-by:
Duke Lee <krnhotwings@gmail.com> Reviewed-by:
Andy Shevchenko <andy.shevchenko@gmail.com> Link: https://lore.kernel.org/r/20220607213654.5567-1-krnhotwings@gmail.comReviewed-by:
-
Bedant Patnaik authored
commit be9d73e6 ("platform/x86: hp-wmi: Fix 0x05 error code reported by several WMI calls") and commit 12b19f14 ("platform/x86: hp-wmi: Fix hp_wmi_read_int() reporting error (0x05)") cause ACPI BIOS Error (bug): Attempt to CreateField of length zero (20211217/dsopcode-133) because of the ACPI method HWMC, which unconditionally creates a Field of size (insize*8) bits: CreateField (Arg1, 0x80, (Local5 * 0x08), DAIN) In cases where args->insize = 0, the Field size is 0, resulting in an error. Fix this by using zero insize only if 0x5 error code is returned Tested on Omen 15 AMD (2020) board ID: 8786. Fixes: be9d73e6 ("platform/x86: hp-wmi: Fix 0x05 error code reported by several WMI calls") Signed-off-by:
Bedant Patnaik <bedant.patnaik@gmail.com> Tested-by:
Jorge Lopez <jorge.lopez2@hp.com> Link: https://lore.kernel.org/r/41be46743d21c78741232a47bbb5f1cdbcc3d21e.camel@gmail.comReviewed-by:
-
Jorge Lopez authored
WMI queries fail on some devices where the ACPI method HWMC unconditionally attempts to create Fields beyond the buffer if the buffer is too small, this breaks essential features such as power profiles: CreateByteField (Arg1, 0x10, D008) CreateByteField (Arg1, 0x11, D009) CreateByteField (Arg1, 0x12, D010) CreateDWordField (Arg1, 0x10, D032) CreateField (Arg1, 0x80, 0x0400, D128) In cases where args->data had zero length, ACPI BIOS Error (bug): AE_AML_BUFFER_LIMIT, Field [D008] at bit offset/length 128/8 exceeds size of target Buffer (128 bits) (20211217/dsopcode-198) was obtained. ACPI BIOS Error (bug): AE_AML_BUFFER_LIMIT, Field [D009] at bit offset/length 136/8 exceeds size of target Buffer (136bits) (20211217/dsopcode-198) The original code created a buffer size of 128 bytes regardless if the WMI call required a smaller buffer or not. This particular behavior occurs in older BIOS and reproduced in OMEN laptops. Newer BIOS handles buffer sizes properly and meets the latest specification requirements. This is the reason why testing with a dynamically allocated buffer did not uncover any failures with the test systems at hand. This patch was tested on several OMEN, Elite, and Zbooks. It was confirmed the patch resolves HPWMI_FAN GET/SET calls in an OMEN Laptop 15-ek0xxx. No problems were reported when testing on several Elite and Zbooks notebooks. Fixes: 4b4967cb ("platform/x86: hp-wmi: Changing bios_args.data to be dynamically allocated") Signed-off-by:
-
- 10 Jun, 2022 7 commits
-
-
August Wikerfors authored
Tested and works on my system. Signed-off-by:
August Wikerfors <git@augustwikerfors.se> Link: https://lore.kernel.org/r/20220608212028.28307-1-git@augustwikerfors.seSigned-off-by:
-
Piotr Chmura authored
Add dmi_system_id of Gigabyte Z690M AORUS ELITE AX DDR4 board. Tested on my PC. Signed-off-by:
Piotr Chmura <chmooreck@gmail.com> Link: https://lore.kernel.org/r/bd83567e-ebf5-0b31-074b-5f6dc7f7c147@gmail.comSigned-off-by:
-
Jiasheng Jiang authored
As platform_driver_register() could fail, it should be better to deal with the return value in order to maintain the code consisitency. Fixes: 86af1d02 ("platform/x86: Support for EC-connected GPIOs for identify LED/button on Barco P50 board") Signed-off-by:
Jiasheng Jiang <jiasheng@iscas.ac.cn> Acked-by:
Peter Korsgaard <peter.korsgaard@barco.com> Link: https://lore.kernel.org/r/20220526090345.1444172-1-jiasheng@iscas.ac.cnSigned-off-by:
-
George D Sworo authored
Add Raptorlake P to the list of the platforms that intel_pmc_core driver supports for pmc_core device. Raptorlake P PCH is based on Alderlake P PCH. Signed-off-by:
George D Sworo <george.d.sworo@intel.com> Reviewed-by:
David E. Box <david.e.box@linux.intel.com> Link: https://lore.kernel.org/r/20220602012617.20100-1-george.d.sworo@intel.comSigned-off-by:
-
David Arcari authored
The probe function pmt_crashlog_probe() may incorrectly reference the 'priv->entry array' as it uses 'i' to reference the array instead of 'priv->num_entries' as it should. This is similar to the problem that was addressed in pmt_telemetry_probe via commit 2cdfa0c2 ("platform/x86/intel: Fix 'rmmod pmt_telemetry' panic"). Cc: "David E. Box" <david.e.box@linux.intel.com> Cc: Hans de Goede <hdegoede@redhat.com> Cc: Mark Gross <markgross@kernel.org> Cc: linux-kernel@vger.kernel.org Signed-off-by:
David Arcari <darcari@redhat.com> Reviewed-by:
-
Michael Shych authored
Fix problem of missing static in struct declaration. Fixes: 662f2482 ("platform/mellanox: Add support for new SN2201 system") Reported-by:
kernel test robot <lkp@intel.com> Signed-off-by:
-
Geert Uytterhoeven authored
Fix a misspelling of the word "platform". Signed-off-by:
Geert Uytterhoeven <geert@linux-m68k.org> Acked-by:
-
- 06 Jun, 2022 3 commits
-
-
Linus Torvalds authored
-
git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfsLinus Torvalds authored
Pull file descriptor fix from Al Viro: "Fix for breakage in #work.fd this window" * tag 'pull-work.fd-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs: fix the breakage in close_fd_get_file() calling conventions change
-
git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mmLinus Torvalds authored
Pull mm hotfixes from Andrew Morton: "Fixups for various recently-added and longer-term issues and a few minor tweaks: - fixes for material merged during this merge window - cc:stable fixes for more longstanding issues - minor mailmap and MAINTAINERS updates" * tag 'mm-hotfixes-stable-2022-06-05' of git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm: mm/oom_kill.c: fix vm_oom_kill_table[] ifdeffery x86/kexec: fix memory leak of elf header buffer mm/memremap: fix missing call to untrack_pfn() in pagemap_range() mm: page_isolation: use compound_nr() correctly in isolate_single_pageblock() mm: hugetlb_vmemmap: fix CONFIG_HUGETLB_PAGE_FREE_VMEMMAP_DEFAULT_ON MAINTAINERS: add maintainer information for z3fold mailmap: update Josh Poimboeuf's email
-
- 05 Jun, 2022 4 commits
-
-
git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mmLinus Torvalds authored
Pull delay-accounting update from Andrew Morton: "A single featurette for delay accounting. Delayed a bit because, unusually, it had dependencies on both the mm-stable and mm-nonmm-stable queues" * tag 'mm-nonmm-stable-2022-06-05' of git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm: delayacct: track delays from write-protect copy
-
Linus Torvalds authored
The bluetooth code uses our bitmap infrastructure for the two bits (!) of connection setup flags, and in the process causes odd problems when it converts between a bitmap and just the regular values of said bits. It's completely pointless to do things like bitmap_to_arr32() to convert a bitmap into a u32. It shoudln't have been a bitmap in the first place. The reason to use bitmaps is if you have arbitrary number of bits you want to manage (not two!), or if you rely on the atomicity guarantees of the bitmap setting and clearing. The code could use an "atomic_t" and use "atomic_or/andnot()" to set and clear the bit values, but considering that it then copies the bitmaps around with "bitmap_to_arr32()" and friends, there clearly cannot be a lot of atomicity requirements. So just use a regular integer. In the process, this avoids the warnings about erroneous use of bitmap_from_u64() which were triggered on 32-bit architectures when conversion from a u64 would access two words (and, surprise, surprise, only one word is needed - and indeed overkill - for a 2-bit bitmap). That was always problematic, but the compiler seems to notice it and warn about the invalid pattern only after commit 0a97953f ("lib: add bitmap_{from,to}_arr64") changed the exact implementation details of 'bitmap_from_u64()', as reported by Sudip Mukherjee and Stephen Rothwell. Fixes: fe92ee64 ("Bluetooth: hci_core: Rework hci_conn_params flags") Link: https://lore.kernel.org/all/YpyJ9qTNHJzz0FHY@debian/ Link: https://lore.kernel.org/all/20220606080631.0c3014f2@canb.auug.org.au/ Link: https://lore.kernel.org/all/20220605162537.1604762-1-yury.norov@gmail.com/Reported-by:
Stephen Rothwell <sfr@canb.auug.org.au> Reported-by:
Sudip Mukherjee <sudipm.mukherjee@gmail.com> Reviewed-by:
Yury Norov <yury.norov@gmail.com> Cc: Luiz Augusto von Dentz <luiz.von.dentz@intel.com> Cc: Marcel Holtmann <marcel@holtmann.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org>
-
Al Viro authored
It used to grab an extra reference to struct file rather than just transferring to caller the one it had removed from descriptor table. New variant doesn't, and callers need to be adjusted. Reported-and-tested-by: syzbot+47dd250f527cb7bebf24@syzkaller.appspotmail.com Fixes: 6319194e ("Unify the primitives for file descriptor closing") Signed-off-by:
Al Viro <viro@zeniv.linux.org.uk>
-
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tipLinus Torvalds authored
Pull x86 SGX fix from Thomas Gleixner: "A single fix for x86/SGX to prevent that memory which is allocated for an SGX enclave is accounted to the wrong memory control group" * tag 'x86-urgent-2022-06-05' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: x86/sgx: Set active memcg prior to shmem allocation
-
