- 03 Feb, 2021 1 commit
-
-
Hans de Goede authored
ib-drm-gpio-pdx86-rtc-wdt for v5.12-1 First part of Intel MID outdated platforms removal. The following is an automated git shortlog grouped by driver: drm/gma500: - Get rid of duplicate NULL checks - Convert to use new SCU IPC API gpio: - msic: Remove driver for deprecated platform - intel-mid: Remove driver for deprecated platform intel_mid_powerbtn: - Remove driver for deprecated platform intel_mid_thermal: - Remove driver for deprecated platform intel_scu_wdt: - Get rid of custom x86 model comparison - Drop SCU notification - Move driver from arch/x86 rtc: - mrst: Remove driver for deprecated platform watchdog: - intel-mid_wdt: Postpone IRQ handler registration till SCU is ready - intel_scu_watchdog: Remove driver for deprecated platform
-
- 02 Feb, 2021 10 commits
-
-
Lubomir Rintel authored
Determined empirically. Signed-off-by:
Lubomir Rintel <lkundrak@v3.sk> Link: https://lore.kernel.org/r/20210126073740.10232-4-lkundrak@v3.skReviewed-by:
Hans de Goede <hdegoede@redhat.com> Signed-off-by:
-
Lubomir Rintel authored
It is not needed. Use a local variable instead. Signed-off-by:
-
Lubomir Rintel authored
Reset ec_priv if probe ends unsuccessfully. Signed-off-by:
-
Pan Bian authored
Put the PCI device rdev on error paths to fix potential reference count leaks. Signed-off-by:
Pan Bian <bianpan2016@163.com> Link: https://lore.kernel.org/r/20210121045005.73342-1-bianpan2016@163.comReviewed-by:
-
Jiaxun Yang authored
Add support to ideapad-laptop for Lenovo platforms that have DYTC version 5 support or newer to use the platform profile feature. Mostly based on Mark Pearson <markpearson@lenovo.com>'s thinkpad-acpi work but massaged to fit ideapad driver. Note that different from ThinkPads, IdeaPads's Thermal Hotkey won't trigger profile switch itself, we'll leave it for userspace programs. Tested on Lenovo Yoga-14S ARE Chinese Edition. Signed-off-by:
Jiaxun Yang <jiaxun.yang@flygoat.com> Reviewed-by:
-
Mark Pearson authored
Add support to thinkpad_acpi for Lenovo platforms that have DYTC version 5 support or newer to use the platform profile feature. This will allow users to determine and control the platform modes between low-power, balanced operation and performance modes. Signed-off-by:
Mark Pearson <markpearson@lenovo.com> Reviewed-by:
-
Hans de Goede authored
-
Nitin Joshi authored
The previous commit adding new sysfs for keyboard language has warning and few code correction has to be done as per new review comments. Below changes has been addressed in this version: - corrected warning. Many thanks to kernel test robot <lkp@intel.com> for reporting and determining this warning. - used sysfs_emit_at() API instead of strcat. - sorted keyboard language array. - removed unwanted space and corrected sentences. Reported-by:
kernel test robot <lkp@intel.com> Signed-off-by:
Nitin Joshi <njoshi1@lenovo.com> Reviewed-by:
-
Lukas Bulwahn authored
Commit d7cbe277 ("platform/x86: thinkpad_acpi: set keyboard language") adds information on keyboard setting to the thinkpad documentation, but made the subsection title underline too short. Hence, make htmldocs warns: Documentation/admin-guide/laptops/thinkpad-acpi.rst:1472: \ WARNING: Title underline too short. Rectify length of subsection title underline. Signed-off-by:
Lukas Bulwahn <lukas.bulwahn@gmail.com> Link: https://lore.kernel.org/r/20210129040849.26740-1-lukas.bulwahn@gmail.comSigned-off-by:
-
Hans de Goede authored
All recent ThinkPad BIOS-es support the GSKL method used to query the keyboard-layout used by the ECFW for the SHIFT + other-key key-press emulation for special keys such as e.g. the '=', '(' and ')' keys above the numpad on 15" models. So just checking for the method is not a good indicator of the model supporting getting/setting the keyboard_lang. On models where this is not supported GSKL succeeds, but it returns METHOD_ERR in the returned integer to indicate that this is not supported on this model. Add a check for METHOD_ERR and return -ENODEV if it is set to avoid registering a non-working keyboard_lang sysfs-attr on models where this is not supported. Cc: Nitin Joshi <njoshi1@lenovo.com> Signed-off-by:
-
- 31 Jan, 2021 1 commit
-
-
Mario Limonciello authored
An upcoming Dell platform is causing a NULL pointer dereference in dell-wmi-sysman initialization. Validate that the input from BIOS matches correct ACPI types and abort module initialization if it fails. Signed-off-by:
Mario Limonciello <mario.limonciello@dell.com> Tested-by:
Perry Yuan <perry_yuan@dell.com> Link: https://lore.kernel.org/r/20210129172654.2326751-1-mario.limonciello@dell.com [hdegoede@redhat.com: Drop redundant release_attributes_data() call] Signed-off-by:
-
- 27 Jan, 2021 2 commits
-
-
Hans de Goede authored
After a rmmod thinkpad_acpi, lockdep pointed out this possible deadlock: Our _show and _store sysfs attr functions get called with the kn->active lock held for the sysfs attr and then take the profile_lock. sysfs_remove_group() also takes the kn->active lock for the sysfs attr, so if we call it with the profile_lock held, then we get an ABBA deadlock. platform_profile_remove() must only be called by drivers which have first *successfully* called platform_profile_register(). Anything else is a driver bug. So the check for cur_profile being set before calling sysfs_remove_group() is not necessary and it can be dropped. It is safe to call sysfs_remove_group() without holding the profile_lock since the attr-group group cannot be re-added until after we clear cur_profile. Change platform_profile_remove() to only hold the profile_lock while clearing the cur_profile, fixing the deadlock. Signed-off-by:
Rafael J. Wysocki <rafael.j.wysocki@intel.com>
-
Jiaxun Yang authored
Add an object pointer to handler callbacks to avoid the need for drivers to have a global variable to get to their driver-data struct. Link: https://lore.kernel.org/linux-acpi/6a29f338-d9e4-150c-81dd-2ffb54f5bc35@redhat.com/ Link: https://lore.kernel.org/r/20210114073429.176462-3-jiaxun.yang@flygoat.comSigned-off-by:
-
- 25 Jan, 2021 21 commits
-
-
Nitin Joshi authored
This patch is to create sysfs entry for setting keyboard language using ASL method. Some thinkpads models like T580 , T590 , T15 Gen 1 etc. has "=", "(',")" numeric keys, which are not displaying correctly, when keyboard language is other than "english". This patch fixes this issue by setting keyboard language to ECFW. Signed-off-by: -
Andy Shevchenko authored
Intel Moorestown and Medfield are quite old Intel Atom based 32-bit platforms, which were in limited use in some Android phones, tablets and consumer electronics more than eight years ago. There are no bugs or problems ever reported outside from Intel for breaking any of that platforms for years. It seems no real users exists who run a more or less fresh kernel on it. Commit 05f4434b ("ASoC: Intel: remove mfld_machine") which has been upstream for a while now confirms this theory. Due to above and to reduce a burden of supporting outdated drivers we remove the support of outdated platforms completely. Signed-off-by:
Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by:
Linus Walleij <linus.walleij@linaro.org> Link: https://lore.kernel.org/r/20210122114145.38813-1-andriy.shevchenko@linux.intel.comSigned-off-by:
-
Andy Shevchenko authored
Intel Moorestown and Medfield are quite old Intel Atom based 32-bit platforms, which were in limited use in some Android phones, tablets and consumer electronics more than eight years ago. There are no bugs or problems ever reported outside from Intel for breaking any of that platforms for years. It seems no real users exists who run a more or less fresh kernel on it. Commit 05f4434b ("ASoC: Intel: remove mfld_machine") which has been upstream for a while now confirms this theory. Due to above and to reduce a burden of supporting outdated drivers we remove the support of outdated platforms completely. Signed-off-by:
-
Hans de Goede authored
Recently userspace has started making more use of SW_TABLET_MODE (when an input-dev reports this). Specifically recent GNOME3 versions will: 1. When SW_TABLET_MODE is reported and is reporting 0: 1.1 Disable accelerometer-based screen auto-rotation 1.2 Disable automatically showing the on-screen keyboard when a text-input field is focussed 2. When SW_TABLET_MODE is reported and is reporting 1: 2.1 Ignore input-events from the builtin keyboard and touchpad (this is for 360° hinges style 2-in-1s where the keyboard and touchpads are accessible on the back of the tablet when folded into tablet-mode) This means that claiming to support SW_TABLET_MODE when it does not actually work / reports correct values has bad side-effects. The check in the hp-wmi code which is used to decide if the input-dev should claim SW_TABLET_MODE support, only checks if the HPWMI_HARDWARE_QUERY is supported. It does *not* check if the hardware actually is capable of reporting SW_TABLET_MODE. This leads to the hp-wmi input-dev claiming SW_TABLET_MODE support, while in reality it will always report 0 as SW_TABLET_MODE value. This has been seen on a "HP ENVY x360 Convertible 15-cp0xxx" and this likely is the case on a whole lot of other HP models. This problem causes both auto-rotation and on-screen keyboard support to not work on affected x360 models. There is no easy fix for this, but since userspace expects SW_TABLET_MODE reporting to be reliable when advertised it is better to not claim/report SW_TABLET_MODE support at all, then to claim to support it while it does not work. To avoid the mentioned problems, add a new enable_tablet_mode_sw module-parameter which defaults to false. Note I've made this an int using the standard -1=auto, 0=off, 1=on triplett, with the hope that in the future we can come up with a better way to detect SW_TABLET_MODE support. ATM the default auto option just does the same as off. BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1918255 Cc: Stefan Brüns <stefan.bruens@rwth-aachen.de> Signed-off-by:Mark Gross <mgross@linux.intel.com> Link: https://lore.kernel.org/r/20210120124941.73409-1-hdegoede@redhat.com
-
Hans de Goede authored
The VBDL ACPI method enables button/switch reporting through the intel-vbtn device. In some cases the embedded-controller (EC) might call Notify() on the intel-vbtn device immediately after the the VBDL call to make sure that the OS is synced with the EC's button and switch state. If we register our notify_handler after evaluating VBDL this means that we might miss the Notify() calls made by the EC to sync the state. E.g. the HP Stream x360 Convertible PC 11 has a VGBS method which always returns 0, independent of the actual SW_TABLET_MODE state of the device; and immediately after the VBDL call it calls Notify(0xCD) or Notify(0xCC) to report the actual state. Move the evaluation of VBDL to after registering our notify_handler so that we don't miss any events. Cc: Elia Devito <eliadevito@gmail.com> Signed-off-by:
-
Hans de Goede authored
Some 2-in-1s have a broken VGBS method, so we cannot get an initial state for the switches from them. Reporting the wrong initial state for SW_TABLET_MODE causes serious problems (touchpad and/or keyboard events being ignored by userspace when reporting SW_TABLET_MODE=1), so on these devices we cannot register an input-dev for the switches at probe time. We can however register an input-dev for the switches as soon as we receive the first switches event, because then we will know the state. Note this mirrors the behavior of recent changs to the intel-hid driver which also registers a separate switches input-dev on receiving the first event on machines with a broken VGBS method. Cc: Elia Devito <eliadevito@gmail.com> Signed-off-by:
-
Hans de Goede authored
Create 2 separate input-devs for buttons and switches, this is a preparation for dynamically registering the switches-input device for devices which are not on the switches allow-list, but do make Notify() calls with an event value from the switches sparse-keymap. This also brings the intel-vbtn driver inline with the intel-hid driver which is doing the same thing. Cc: Elia Devito <eliadevito@gmail.com> Signed-off-by:
-
Hans de Goede authored
Rework the wakeup path inside notify_handler() to special case the buttons (KE_KEY) case instead of the switches case. In case of a button wake event we want to skip reporting this, mirroring how the drivers/acpi/button.c code skips the reporting in the wakeup case (suspended flag set) too. The reason to skip reporting in this case is that some Linux desktop-environments will immediately resuspend if we report an evdev event for the power-button press on wakeup. Before this commit the skipping of the button-press was done in a round-about way: In case of a wakeup the regular sparse_keymap_report_event() would always be skipped by an early return, and then to avoid not reporting switch changes on wakeup there was a special KE_SW path with a duplicate sparse_keymap_report_event() call. This commit refactors the wakeup handling to explicitly skip the reporting for button wake events, while using the regular reporting path for non button (switches) wakeup events. No intentional functional impact. Cc: Elia Devito <eliadevito@gmail.com> Signed-off-by:
-
Andy Shevchenko authored
Switch the platform code to use x86_id_table and accompanying API instead of custom comparison against x86 CPU model. This is one of the last users of custom API for that and following changes will remove it for the good. Signed-off-by:
Guenter Roeck <linux@roeck-us.net>
-
Andy Shevchenko authored
Since SCU code along with the Intel MID watchdog driver has been refactored in a way that latter will be probed only after the former has been come to live, the notification code is bogus and not needed. Remove it for good. Signed-off-by:
-
Andy Shevchenko authored
The ACPI-enabled Intel MID platforms neither have WDAT table nor proper IDs to instantiate watchdog device. In order to keep them working move the board code from arch/x86 to drivers/platform/x86. Note, the complete SFI support is going to be removed, that's why PDx86 has been chosen as a new home for it. This is the only device which needs additional code so far. Signed-off-by:
-
Andy Shevchenko authored
When SCU is not ready and CONFIG_DEBUG_SHIRQ=y we got deferred probe followed by fired test IRQ which immediately makes kernel panic. Fix this by delaying IRQ handler registration till SCU is ready. Fixes: 80ae679b ("watchdog: intel-mid_wdt: Convert to use new SCU IPC API") Signed-off-by:
Mika Westerberg <mika.westerberg@linux.intel.com>
-
Andy Shevchenko authored
Intel Moorestown and Medfield are quite old Intel Atom based 32-bit platforms, which were in limited use in some Android phones, tablets and consumer electronics more than eight years ago. There are no bugs or problems ever reported outside from Intel for breaking any of that platforms for years. It seems no real users exists who run more or less fresh kernel on it. The commit 05f4434b ("ASoC: Intel: remove mfld_machine") also in align with this theory. Due to above and to reduce a burden of supporting outdated drivers we remove the support of outdated platforms completely. Signed-off-by:
-
Andy Shevchenko authored
Intel Moorestown and Medfield are quite old Intel Atom based 32-bit platforms, which were in limited use in some Android phones, tablets and consumer electronics more than eight years ago. There are no bugs or problems ever reported outside from Intel for breaking any of that platforms for years. It seems no real users exists who run more or less fresh kernel on it. The commit 05f4434b ("ASoC: Intel: remove mfld_machine") also in align with this theory. Due to above and to reduce a burden of supporting outdated drivers we remove the support of outdated platforms completely. Signed-off-by:
Alexandre Belloni <alexandre.belloni@bootlin.com> Acked-by:
-
Andy Shevchenko authored
Intel Moorestown and Medfield are quite old Intel Atom based 32-bit platforms, which were in limited use in some Android phones, tablets and consumer electronics more than eight years ago. There are no bugs or problems ever reported outside from Intel for breaking any of that platforms for years. It seems no real users exists who run more or less fresh kernel on it. The commit 05f4434b ("ASoC: Intel: remove mfld_machine") also in align with this theory. Due to above and to reduce a burden of supporting outdated drivers we remove the support of outdated platforms completely. Signed-off-by:
-
Andy Shevchenko authored
Intel Moorestown and Medfield are quite old Intel Atom based 32-bit platforms, which were in limited use in some Android phones, tablets and consumer electronics more than eight years ago. There are no bugs or problems ever reported outside from Intel for breaking any of that platforms for years. It seems no real users exists who run more or less fresh kernel on it. The commit 05f4434b ("ASoC: Intel: remove mfld_machine") also in align with this theory. Due to above and to reduce a burden of supporting outdated drivers we remove the support of outdated platforms completely. Signed-off-by:
-
Andy Shevchenko authored
Intel Moorestown and Medfield are quite old Intel Atom based 32-bit platforms, which were in limited use in some Android phones, tablets and consumer electronics more than eight years ago. There are no bugs or problems ever reported outside from Intel for breaking any of that platforms for years. It seems no real users exists who run more or less fresh kernel on it. The commit 05f4434b ("ASoC: Intel: remove mfld_machine") also in align with this theory. Due to above and to reduce a burden of supporting outdated drivers we remove the support of outdated platforms completely. Signed-off-by:
-
Andy Shevchenko authored
Intel Moorestown and Medfield are quite old Intel Atom based 32-bit platforms, which were in limited use in some Android phones, tablets and consumer electronics more than eight years ago. There are no bugs or problems ever reported outside from Intel for breaking any of that platforms for years. It seems no real users exists who run more or less fresh kernel on it. The commit 05f4434b ("ASoC: Intel: remove mfld_machine") also in align with this theory. Due to above and to reduce a burden of supporting outdated drivers we remove the support of outdated platforms completely. Moreover this code duplicates gpio-pxa since the IP has been derived from XScale implementation. If anybody wants to resurrect this it has to be part of gpio-pxa.c. Signed-off-by:
-
Andy Shevchenko authored
Since GPIOs are optional we don't need to repeat checks that are done in the GPIO API. Remove them for good. Signed-off-by:
Patrik Jakobsson <patrik.r.jakobsson@gmail.com> Acked-by:
-
Andy Shevchenko authored
Convert the GMA500 driver to use the new SCU IPC API. This allows us to get rid of the duplicate PMC IPC implementation which is now covered in SCU IPC driver. Signed-off-by:
-
Jiaxun Yang authored
Drop the const qualifier from the static global cur_profile pointer declaration. This is a preparation patch for passing the cur_profile pointer as parameter to the profile_get() and profile_set() callbacks so that drivers dynamically allocating their driver-data struct, with their platform_profile_handler struct embedded, can use this pointer to get to their driver-data. Note this also requires dropping the const from the pprof platform_profile_register() function argument. Dropping this const is not a problem, non of the queued up consumers of platform_profile_register() actually pass in a const pointer. Link: https://lore.kernel.org/linux-acpi/5e7a4d87-52ef-e487-9cc2-8e7094beaa08@redhat.com/ Link: https://lore.kernel.org/r/20210114073429.176462-2-jiaxun.yang@flygoat.comSuggested-by:
-
- 18 Jan, 2021 5 commits
-
-
Yue Zou authored
Remove a superfluous semicolon after function definition. Signed-off-by:
Yue Zou <zouyue3@huawei.com> Link: https://lore.kernel.org/r/20210118010137.214378-1-zouyue3@huawei.comSigned-off-by:
-
Jeannie Stevenson authored
This commit enables dual fan control for the new Lenovo P53 and P73 laptop models. Signed-off-by:
Jeannie Stevenson <jeanniestevenson@protonmail.com> Link: https://lore.kernel.org/r/Pn_Xii4XYpQRFtgkf4PbNgieE89BAkHgLI1kWIq-zFudwh2A1DY5J_DJVHK06rMW_hGPHx_mPE33gd8mg9-8BxqJTaSC6hhPqAsfZlcNGH0=@protonmail.comSigned-off-by:
-
Henrique de Moraes Holschuh authored
Update my email address in MAINTAINERS to the one I have been using for commits, Signed-off-by and Acked-by tags. Only two ancient commits had the old ibm-acpi@hmh.eng.br, so it is unlikely to justify a .mailmap entry. Note that ibm-acpi@hmh.eng.br does work as a way to contact me, but apparently it is best when MAINTAINERS entries match commit email addresses ;-) Signed-off-by:
Henrique de Moraes Holschuh <hmh@hmh.eng.br> Link: https://lore.kernel.org/r/20210115184721.32546-1-hmh@hmh.eng.brSigned-off-by:
-
Hans de Goede authored
The recently added thermal policy support makes a hp_wmi_perform_query(0x4c, ...) call on older devices which do not support thermal policies this causes the following warning to be logged (seen on a HP Stream x360 Convertible PC 11): [ 26.805305] hp_wmi: query 0x4c returned error 0x3 Error 0x3 is HPWMI_RET_UNKNOWN_COMMAND error. This commit silences the warning for unknown-command errors, silencing the new warning. Cc: Elia Devito <eliadevito@gmail.com> Fixes: 81c93798 ("platform/x86: hp-wmi: add support for thermal policy") Link: https://lore.kernel.org/r/20210114232744.154886-1-hdegoede@redhat.comSigned-off-by:
-
Hans de Goede authored
THe HP Stream x360 Convertible PC 11 DSDT has the following VGBS function: Method (VGBS, 0, Serialized) { If ((^^PCI0.LPCB.EC0.ROLS == Zero)) { VBDS = Zero } Else { VBDS = Zero } Return (VBDS) /* \_SB_.VGBI.VBDS */ } Which is obviously wrong, because it always returns 0 independent of the 2-in-1 being in laptop or tablet mode. This causes the intel-vbtn driver to initially report SW_TABLET_MODE = 1 to userspace, which is known to cause problems when the 2-in-1 is actually in laptop mode. During earlier testing this turned out to not be a problem because the 2-in-1 would do a Notify(..., 0xCC) or Notify(..., 0xCD) soon after the intel-vbtn driver loaded, correcting the SW_TABLET_MODE state. Further testing however has shown that this Notify() soon after the intel-vbtn driver loads, does not always happen. When the Notify does not happen, then intel-vbtn reports SW_TABLET_MODE = 1 resulting in a non-working touchpad. IOW the tablet-mode reporting is not reliable on this device, so it should be dropped from the allow-list, fixing the touchpad sometimes not working. Fixes: 8169bd3e ("platform/x86: intel-vbtn: Switch to an allow-list for SW_TABLET_MODE reporting") Link: https://lore.kernel.org/r/20210114143432.31750-1-hdegoede@redhat.comSigned-off-by:
-
