- 07 Dec, 2020 7 commits
-
-
Hans de Goede authored
Some HP x360 models have an ACPI VGBS method which sets bit 4 instead of bit 6 when NOT in tablet mode at boot. Inspecting all the DSDTs in my DSDT collection shows only one other model, the Medion E1239T ever setting bit 4 and it always sets this together with bit 6. So lets treat bit 4 as a second bit which when set indicates the device not being in tablet-mode, as we already do for bit 6. While at it also prefix all VGBS constant defines with "VGBS_". Note this wrokaround was first added to the kernel as commit d8233468 ("platform/x86: intel-vbtn: Fix SW_TABLET_MODE always reporting 1 on the HP Pavilion 11 x360"). After commit 8169bd3e ("platform/x86: intel-vbtn: Switch to an allow-list for SW_TABLET_MODE reporting") got added to the kernel this was reverted, because with the new allow-list approach the workaround was no longer necessary for the model on which the issue was first reported. But it turns out that the workaround is still necessary because some affected models report a chassis-type of 31 which is on the allow-list. BugLink: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1894017 Fixes: 21d64817 ("platform/x86: intel-vbtn: Revert "Fix SW_TABLET_MODE always reporting 1 on the HP Pavilion 11 x360"") Signed-off-by:
Hans de Goede <hdegoede@redhat.com>
-
Srinivas Pandruvada authored
Use PCI_VDEVICE and PCI_DEVICE_DATA macros. No functional changes are expected. Signed-off-by:
Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Link: https://lore.kernel.org/r/20201204015746.1168941-3-srinivas.pandruvada@linux.intel.comSigned-off-by:
-
Srinivas Pandruvada authored
The mmio offset range can be different based on the PCI device id. Here for INTEL_RAPL_PRIO_DEVID_1, the range is increased from 45 to 64. Pass the range as the driver_data. Also account for different ranges during save/restore via suspend/resume callbacks. Signed-off-by:
-
Srinivas Pandruvada authored
The address should be aligned to 4 byte boundary. So send an error for unaligned address. Signed-off-by:
-
Daniel Drake authored
Sending the switch state change twice within the same frame is invalid evdev protocol and only works if the client handles keys immediately as well. Processing events immediately is incorrect, it forces a fake order of events that does not exist on the device. Recent versions of libinput changed to only process the device state and SYN_REPORT time, so now the key event is lost. Same fix as 'commit <bff5bf9d> ("platform/x86: asus-wireless: send an EV_SYN/SYN_REPORT between state changes")' Signed-off-by:
Daniel Drake <drake@endlessos.org> Signed-off-by:
Chris Chiu <chiu@endlessos.org> Link: https://lore.kernel.org/r/20201207064322.13992-1-chiu@endlessos.orgSigned-off-by:
-
Divya Bharathi authored
BIOS sets incorrect value (zero) when SET value passed for integer attribute with + sign. Added workaround to remove + sign before passing input to BIOS. Co-developed-by:
Mario Limonciello <mario.limonciello@dell.com> Signed-off-by:
Prasanth KSR <prasanth.ksr@dell.com> Signed-off-by:
Divya Bharathi <divya.bharathi@dell.com> Link: https://lore.kernel.org/r/20201202131935.307372-1-divya.bharathi@dell.comSigned-off-by:
-
Arnd Bergmann authored
The only reference to the mlxplat_mlxcpld_psu[] array got removed, so there is now a warning from clang: drivers/platform/x86/mlx-platform.c:322:30: error: variable 'mlxplat_mlxcpld_psu' is not needed and will not be emitted [-Werror,-Wunneeded-internal-declaration] static struct i2c_board_info mlxplat_mlxcpld_psu[] = { Remove the array as well and adapt the ARRAY_SIZE() call accordingly. Fixes: 912b3415 ("platform/x86: mlx-platform: Remove PSU EEPROM from MSN274x platform configuration") Signed-off-by:Arnd Bergmann <arnd@arndb.de> Acked-by:
Vadim Pasternak <vadimp@nvidia.com> Link: https://lore.kernel.org/r/20201203223105.1195709-1-arnd@kernel.orgSigned-off-by:
-
- 02 Dec, 2020 3 commits
-
-
Tom Rix authored
The macro use will already have a semicolon. Signed-off-by:
Tom Rix <trix@redhat.com> Link: https://lore.kernel.org/r/20201127181024.2771890-1-trix@redhat.comSigned-off-by:
-
Qinglang Miao authored
Fix to return the error code -ENODEV when fails to init wmi and smm. Fixes: 41e36f2f ("platform/x86: dell-smbios: Link all dell-smbios-* modules together") Reported-by:
Hulk Robot <hulkci@huawei.com> Signed-off-by:
Qinglang Miao <miaoqinglang@huawei.com> Reviewed-by:
-
Carlos Garnacho authored
This 2-in-1 model (Product name: Switch SA5-271) features a SW_TABLET_MODE that works as it would be expected, both when detaching the keyboard and when folding it behind the tablet body. It used to work until the introduction of the allow list at commit 8169bd3e ("platform/x86: intel-vbtn: Switch to an allow-list for SW_TABLET_MODE reporting"). Add this model to it, so that the Virtual Buttons device announces the EV_SW features again. Fixes: 8169bd3e ("platform/x86: intel-vbtn: Switch to an allow-list for SW_TABLET_MODE reporting") Cc: stable@vger.kernel.org Signed-off-by:
Carlos Garnacho <carlosg@gnome.org> Link: https://lore.kernel.org/r/20201201135727.212917-1-carlosg@gnome.orgSigned-off-by:
-
- 26 Nov, 2020 3 commits
-
-
Vadim Pasternak authored
Remove PSU EEPROM configuration for systems class equipped with Mellanox chip Spectrum and ATOM CPU - system types MSN274x. Till now all the systems from this class used few types of power units, all equipped with EEPROM device with address space two bytes. Thus, all these devices have been handled by EEPROM driver "24c02". There is a new requirement is to support power unit replacement by "off the shelf" device, matching electrical required parameters. Such device can be equipped with different EEPROM type, which could be one byte address space addressing or even could be not equipped with EEPROM. In such case "24c02" will not work. Fixes: ef08e14a ("platform/x86: mlx-platform: Add support for new msn274x system type") Signed-off-by:
-
Vadim Pasternak authored
Remove PSU EEPROM configuration for systems class equipped with Mellanox chip Spectrum and Celeron CPU - system types MSN2700, MSN2100. Till now all the systems from this class used few types of power units, all equipped with EEPROM device with address space two bytes. Thus, all these devices have been handled by EEPROM driver "24c02". There is a new requirement is to support power unit replacement by "off the shelf" device, matching electrical required parameters. Such device can be equipped with different EEPROM type, which could be one byte address space addressing or even could be not equipped with EEPROM. In such case "24c02" will not work. Fixes: c6acad68 ("platform/mellanox: mlxreg-hotplug: Modify to use a regmap interface") Fixes: ba814fdd ("platform/x86: mlx-platform: Use defines for bus assignment") Signed-off-by:
-
Matthias Maier authored
This commit enables dual fan control for the following new Lenovo models: P15, P15v. Signed-off-by:
Matthias Maier <tamiko@43-1.org> Link: https://lore.kernel.org/r/20201126000416.2459645-2-tamiko-ibm-acpi-devel@43-1.orgSigned-off-by:
-
- 25 Nov, 2020 1 commit
-
-
Mark Pearson authored
Add support to thinkpad_acpi for returning the status of the palm sensor. This patch builds on the work done previously for the input device implementation (which was not needed). Both lap and palm sensor are using sysfs and they are combined into the proxsensor block. Note: On some platforms, because of an issue in the HW implementation, the palm sensor presence may be incorrectly advertised as always enabled even if a palm sensor is not present. The palm sensor is intended for WWAN transmission power control and should be available and correct on all WWAN enabled systems. It is not recommended to use this interface for other use cases. Signed-off-by:
Mark Pearson <markpearson@lenovo.com> Link: https://lore.kernel.org/r/20201124181154.547518-1-markpearson@lenovo.comSigned-off-by:
-
- 24 Nov, 2020 11 commits
-
-
Vasiliy Kupriakov authored
When user presses Fn-F5, the driver automatically changes throttle thermal policy (or fan boost mode, depending on laptop model). It would be convenient for userspace software to be able to poll on corresponding sysfs variable. For example, to show a notification about mode change. Note that there is currently no way to handle Fn-F5 from userspace directly, driver does not pass it. Signed-off-by:
Vasiliy Kupriakov <rublag-ns@yandex.ru> Link: https://lore.kernel.org/r/20200828214932.20866-2-rublag-ns@yandex.ruSigned-off-by:
-
Hans de Goede authored
Add touchscreen info for the Irbis TW118 tablet. Reported-and-tested-by:
russianneuromancer <russianneuromancer@ya.ru> Signed-off-by:
-
Max Verevkin authored
The Pavilion 13 x360 PC has a chassis-type which does not indicate it is a convertible, while it is actually a convertible. Add it to the dmi_switches_allow_list. Signed-off-by:
Max Verevkin <me@maxverevkin.tk> Link: https://lore.kernel.org/r/20201124131652.11165-1-me@maxverevkin.tkSigned-off-by:
-
Benjamin Berg authored
The lid state may change while the machine is suspended. As such, we may need to re-check the state at wake-up time (at least when waking up from hibernation). Add the appropriate call to the resume handler in order to sync the SW_TABLET_MODE switch state with the hardware state. Fixes: dda3ec0a ("platform/x86: thinkpad_acpi: Implement tablet mode using GMMS method") BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=210269Signed-off-by:
Benjamin Berg <bberg@redhat.com> Acked-by:
Henrique de Moraes Holschuh <hnh@hmh.eng.br> Link: https://lore.kernel.org/r/20201123132157.866303-1-benjamin@sipsolutions.netSigned-off-by:
-
Hans de Goede authored
Add the Acer Aspire Switch 10E SW3-016 to the list of models which use the Acer Switch WMI interface for reporting SW_TABLET_MODE. Signed-off-by:
-
Kaixu Xia authored
The commit 78429e55 ("platform/x86: toshiba_acpi: Clean up variable declaration") cleans up variable declaration in video_proc_write(). Seems it does the variable assignment in the wrong place, this results in dead code and changes the source code logic. Fix it by doing the assignment at the beginning of the funciton. Fixes: 78429e55 ("platform/x86: toshiba_acpi: Clean up variable declaration") Reported-by:
Tosk Robot <tencent_os_robot@tencent.com> Signed-off-by:
Kaixu Xia <kaixuxia@tencent.com> Link: https://lore.kernel.org/r/1606024177-16481-1-git-send-email-kaixuxia@tencent.comSigned-off-by:
-
Maximilian Luz authored
In addition to a 13" version, there is also a 15" (business) version of the Surface Laptop 3 based on Intel CPUs. This version also handles wakeup by lid via (unmarked) GPEs, so add support for it as well. Signed-off-by:
Maximilian Luz <luzmaximilian@gmail.com> Link: https://lore.kernel.org/r/20201113223935.2073847-1-luzmaximilian@gmail.comSigned-off-by:
-
Dan Carpenter authored
The "ns->attr_grp" pointer can be NULL so this error handling code needs to check for that to avoid an Oops. Fixes: e2729113 ("platform/x86: Intel PMT class driver") Signed-off-by:
Dan Carpenter <dan.carpenter@oracle.com> Reviewed-by:
David E. Box <david.e.box@linux.intel.com> Link: https://lore.kernel.org/r/20201117072251.GC1111239@mwandaSigned-off-by:
-
Andy Shevchenko authored
Use device_get_match_data() to get driver data instead of boilerplate code. Signed-off-by:
Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://lore.kernel.org/r/20201105110530.27888-4-andriy.shevchenko@linux.intel.comSigned-off-by:
-
Andy Shevchenko authored
Common pattern of handling deferred probe can be simplified with dev_err_probe(). Less code and the error value gets printed. Signed-off-by:
-
Andy Shevchenko authored
The driver depends on ACPI, ACPI_PTR() resolution is always the same. Otherwise a compiler may produce a warning. That said, the rule of thumb either ugly ifdeffery with ACPI_PTR or none should be used in a driver. Signed-off-by:
-
- 10 Nov, 2020 11 commits
-
-
Kenneth Chan authored
Take over maintainership of panasonic-laptop from Harald Welte. Signed-off-by:
Kenneth Chan <kenneth.t.chan@gmail.com> Acked-by:
Harald Welte <laforge@gnumonks.org> Link: https://lore.kernel.org/r/20200825101341.5699-1-kenneth.t.chan@gmail.comSigned-off-by:
-
Kenneth Chan authored
Panasonic laptops (at least from CF-W4 onwards) have dedicated firmware registers for saving ac/dc and current brightness. They are a bit confusing so here's some explanations: AC_MIN_BRIGHT, AC_MAX_BRIGHT, DC_MIN_BRIGHT, DC_MAX_BRIGHT: Read-only. Values: 0x01 and 0x15 respectively. AC_CUR_BRIGHT, DC_CUR_BRIGHT: Read-Write. 0x00-0xFF. Store user-defined AC/DC brightness. However, they do not represent current brightness so they should be named AC_BRIGHT and DC_BRIGHT instead. CUR_BRIGHT (present since CF-W4): Read-Write. 0x00-0xFF. It sets the current brightness. It won't update itself if brightness is changed via other means, e.g. acpi_video0. Another CUR_BRIGHT (added since CF-W5): Read-Write. 0x01-0x15. Its value always synchronizes with current brightness. Not implemented in this version. Currently the backlight API interacts with AC_CUR_BRIGHT (probably because it's the only bl register available in earlier models?). This patch adds sysfs attributes for AC_CUR_BRIGHT, DC_CUR_BRIGHT and CUR_BRIGHT. It also fixes the error of https://lkml.org/lkml/2020/8/19/1264. PS: I think the backlight API should interact with CUR_BRIGHT instead of AC_CUR_BRIGHT. But it involves complications like mapping between 0x01-0x15 or 0x00-0x14 (the backlight API) and 0x00-0xFF (CUR_BRIGHT). I'll leave the discussion for a later version. Signed-off-by:
-
Kenneth Chan authored
Add battery charging threshold (aka ECO mode) support. NOTE: The state of ECO mode is persistent until the next POST cycle which reset it to previous state. Signed-off-by:
-
Kenneth Chan authored
Sometimes double ACPI events are triggered for brightness, vol and mute hotkeys. This patch fixes it. Signed-off-by:
-
Kenneth Chan authored
Add write support to the mute platform device Signed-off-by:
-
Kenneth Chan authored
The return value of the sticky key on some models (e.g. CF-W5) do not reflect its state. How to retrieve its state from firmware is unknown. The safest bet is to reset it at module init and store its state in pcc struct. Signed-off-by:
-
Kenneth Chan authored
Change platform device function names for consistency with other modules Signed-off-by:
-
Kenneth Chan authored
In reply to https://lkml.org/lkml/2020/8/19/186 to split MODULE_AUTHOR() per macro call. Signed-off-by:
-
Kenneth Chan authored
Replace ACPI prints with pr_*() macros for consistency with other platform devices. Clean up obsolete ACPI_HOTKEY_COMPONENT code. Signed-off-by:
-
Kenneth Chan authored
The physical optical drive switch is present in Y and W series that switches on the drive but fails to turn it off. The idea is to be able to toggle the drive power by software and/or hardware. This patch merges Martin Lucina <mato@kotelna.sk>'s work that took care of the software part. Code is also added for the physical switch to power off the drive. Signed-off-by:
-
Timo Witte authored
Got a dmesg message on my AMD Renoir based Acer laptop: "acer_wmi: Unknown key number - 0x84" when toggling keyboard background light Signed-off-by:
Timo Witte <timo.witte@gmail.com> Reviewed-by:
"Lee, Chun-Yi" <jlee@suse.com> Link: https://lore.kernel.org/r/20200804001423.36778-1-timo.witte@gmail.comSigned-off-by:
-
- 09 Nov, 2020 4 commits
-
-
Zhen Gong authored
According to the ACPI spec 9.1.1 _DSM (Device Specific Method), intel_hid_dsm_fn_mask, acquired from function index 0, is "a buffer containing one bit for each function index". When validitaing fn_index, it should be compared with corresponding bit. This buffer is usually longer than a byte. Depending on whether INTEL_HID_DSM_HEBC_V2_FN exist, it could be either "Buffer (0x02) { 0xFF, 0x01 }" or "Buffer (0x02) { 0xFF, 0x03 }". Probably it won't grow larger according to the description. On older platforms, available functions could be fewer or not supported at all, i.e., "Buffer (One) { 0x00 }". Signed-off-by:Zhen Gong <zhengong@usc.edu> Link: https://lore.kernel.org/r/CAJCLVRCyp0ASdWTx-PxsrDC9zFBPw0U2AtPip+_Hpj2r5gUPwA@mail.gmail.comSigned-off-by:
-
Kaixu Xia authored
Fix the following coccinelle warnings: ./drivers/platform/x86/intel_pmc_core.c:932:1-16: WARNING: Assignment of 0/1 to bool variable Signed-off-by:
Andy Shevchenko <andy.shevchenko@gmail.com> Link: https://lore.kernel.org/r/1604753621-7387-1-git-send-email-kaixuxia@tencent.comSigned-off-by:
-
Shyam Sundar S K authored
AMD Power Management Controller driver a.k.a. amd-pmc driver is the controller which is meant for the final S2Idle transaction that goes to the PMFW running on the AMD SMU (System Management Unit) responsible for tuning of the VDD. Once all the monitored list or the idle constraints are met, this driver would go and set the OS_HINT (meaning all the devices have reached to their lowest state possible) via the SMU mailboxes. This driver would also provide some debug capabilities via debugfs. Signed-off-by:
Shyam Sundar S K <Shyam-sundar.S-k@amd.com> Reviewed-by:
-
Hans de Goede authored
The Thinkpad Yoga 11e 4th gen with the N3450 / Celeron CPU only has one battery which is named BAT1 instead of the expected BAT0, add a quirk for this. This fixes not being able to set the charging tresholds on this model; and this alsoe fixes the following errors in dmesg: ACPI: \_SB_.PCI0.LPCB.EC__.HKEY: BCTG evaluated but flagged as error thinkpad_acpi: Error probing battery 2 battery: extension failed to load: ThinkPad Battery Extension battery: extension unregistered: ThinkPad Battery Extension Note that the added quirk is for the "R0K" BIOS versions which are used on the Thinkpad Yoga 11e 4th gen's with a Celeron CPU, there is a separate "R0L" BIOS for the i3/i5 based versions. This may also need the same quirk, but if that really is necessary is unknown. Signed-off-by:
-
