- 18 Mar, 2022 3 commits
-
-
Mark Pearson authored
Implementation of certificate authentication feature for Lenovo platforms. This allows for signed updates of BIOS settings. Functionality supported: - Cert support available check. At initialisation check if BIOS supports certification authentication and if a certificate is installed. Enable the sysfs nodes appropriately - certificate and signature authentication attributes to enable a user to install, update and delete a certificate using signed signatures - certificate_thumbprint to confirm installed certificate details - support to go from certificate to password based authentication - signature and save_signature attributes needed for setting BIOS attributes using certificate authentication. Tested on X1 Carbon G10 and X1 Yoga G7. This feature is not generally available yet but will be released later this year. Note, I also cleaned up the formating of the GUIDs when I was adding the new defines. Hope that's OK to combine in this commit. Signed-off-by:
Mark Pearson <markpearson@lenovo.com> Link: https://lore.kernel.org/r/20220317214008.3459-2-markpearson@lenovo.comReviewed-by:
Hans de Goede <hdegoede@redhat.com> Signed-off-by:
-
Mark Pearson authored
Certificate based authentication is available as an alternative to password based authentication. The WMI commands are cryptographically signed using a separate signing server and will be verified by the BIOS before being accepted. This commit details the fields that are needed to support that implementation. At present the changes are intended for Lenovo platforms, but have been designed to keep them as flexible as possible for future implementations from other vendors. Signed-off-by:
-
Mario Limonciello authored
Currently if STB is disabled but an earlier function reported an error an incorrect error will be emitted about failing to write to STB. Correct this logic error by only showing errors when STB is enabled. Suggested-by:
Mario Limonciello <mario.limonciello@amd.com> Link: https://lore.kernel.org/r/20220317190301.6818-1-mario.limonciello@amd.comReviewed-by:
-
- 17 Mar, 2022 5 commits
-
-
Mario Limonciello authored
A workaround was previously introduced as part of commit 646f429ec2de ("platform/x86: amd-pmc: Set QOS during suspend on CZN w/ timer wakeup") to prevent CPUs from going into the deepest state during the execution of the `noirq` stage of `amd_pmc`. As `amd_pmc` has been pushed to the last step for suspend on AMD platforms, this workaround is no longer necessary. Signed-off-by: -
Mario Limonciello authored
The return type for the s2idle callbacks is 'void', so any errors that occur will no longer be displayed. Output these error codes in the messages in case of any failures. Signed-off-by:
-
Mario Limonciello authored
The `OS_HINT` message is supposed to indicate that everything else that is supposed to go into the deepest state has done so. This assumption is invalid as: 1) The CPUs will still go in and out of the deepest state 2) Other devices may still run their `noirq` suspend routines 3) The LPS0 ACPI device will still run To more closely mirror how this works on other operating systems, move the `amd-pmc` suspend to the very last thing before the s2idle loop via an lps0 callback. Fixes: 8d89835b ("PM: suspend: Do not pause cpuidle in the suspend-to-idle path") Signed-off-by:
-
Mario Limonciello authored
Currenty the latest thing run during a suspend to idle attempt is the LPS0 `prepare_late` callback and the earliest thing is the `resume_early` callback. There is a desire for the `amd-pmc` driver to suspend later in the suspend process (ideally the very last thing), so create a callback that it or any other driver can hook into to do this. Signed-off-by:
Rafael J. Wysocki <rafael.j.wysocki@intel.com> Link: https://lore.kernel.org/r/20220317141445.6498-1-mario.limonciello@amd.comReviewed-by:
-
Tom Rix authored
Clang static analysis returns this false positive thinkpad_acpi.c:8926:19: warning: The left operand of '!=' is a garbage value (status != 0) ? "enabled" : "disabled", status); ~~~~~~ ^ The return of fan_get_status* is checked inconsistenly. Sometime ret < 0 is an error, sometimes !ret. Both fan_get_status() and fan_get_status_safe() return 0 on success and return negative otherwise. Change the checks for error, ret < 0, into checks for not success, !ret. Signed-off-by:
Tom Rix <trix@redhat.com> Link: https://lore.kernel.org/r/20220312145327.1398510-1-trix@redhat.comReviewed-by:
-
- 15 Mar, 2022 2 commits
-
-
Enver Balalic authored
As it turns out, these laptops have 2 thermal profile versions. A previous patch added support for v0, this patch adds support for v1 thermal policies that are in use on some devices. We obtain the thermal policy version by querying the get system design data WMI call and looking at the fourth byte it returns, except if the system board DMI Board ID is in a specific array that the windows command center app overrides to thermal policy v0 for some reason. Signed-off-by:
Enver Balalic <balalic.enver@gmail.com> Link: https://lore.kernel.org/r/20220314121453.kjszdciymtg6ctbq@omenReviewed-by:
-
Jorge Lopez authored
The purpose of this patch is to remove 128 bytes buffer limitation imposed in bios_args structure. A limiting factor discovered during this investigation was the struct bios_args.data size restriction. The data member size limits all possible WMI commands to those requiring buffer size of 128 bytes or less. Several WMI commands and queries require a buffer size larger than 128 bytes hence limiting current and feature supported by the driver. It is for this reason, struct bios_args.data changed and is dynamically allocated. hp_wmi_perform_query function changed to handle the memory allocation and release of any required buffer size. All changes were validated on a HP ZBook Workstation notebook, HP EliteBook x360, and HP EliteBook 850 G8. Additional validation was included in the test process to ensure no other commands were incorrectly handled. Signed-off-by:
Jorge Lopez <jorge.lopez2@hp.com> Link: https://lore.kernel.org/r/20220310210853.28367-5-jorge.lopez2@hp.comReviewed-by:
-
- 14 Mar, 2022 3 commits
-
-
Jorge Lopez authored
Several WMI queries leverage hp_wmi_read_int function to read their data. hp_wmi_read_int function was corrected in a previous patch. Now, this function invokes hp_wmi_perform_query with input parameter of size zero and the output buffer of size 4. WMI commands calling hp_wmi_perform_query with input buffer size value of zero are listed below. HPWMI_DISPLAY_QUERY HPWMI_HDDTEMP_QUERY HPWMI_ALS_QUERY HPWMI_HARDWARE_QUERY HPWMI_WIRELESS_QUERY HPWMI_BIOS_QUERY HPWMI_FEATURE_QUERY HPWMI_HOTKEY_QUERY HPWMI_FEATURE2_QUERY HPWMI_WIRELESS2_QUERY HPWMI_POSTCODEERROR_QUERY HPWMI_THERMAL_PROFILE_QUERY HPWMI_FAN_SPEED_MAX_GET_QUERY Invoking those WMI commands with an input buffer size greater than zero will cause error 0x05 to be returned. All WMI commands executed by the driver were reviewed and changes were made to ensure the expected input and output buffer size match the WMI specification. Changes were validated on a HP ZBook Workstation notebook, HP EliteBook x360, and HP EliteBook 850 G8. Additional validation was included in the test process to ensure no other commands were incorrectly handled. Signed-off-by:
-
Jorge Lopez authored
The purpose of this patch is to introduce a fix and removal of the current hack when determining tablet mode status. Determining the tablet mode status requires reading Byte 0 bit 2 as reported by HPWMI_HARDWARE_QUERY. The investigation identified the failure was rooted in two areas: HPWMI_HARDWARE_QUERY failure (0x05) and reading Byte 0, bit 2 only to determine the table mode status. HPWMI_HARDWARE_QUERY WMI failure also rendered the dock state value invalid. The latest changes use SMBIOS Type 3 (chassis type) and WMI Command 0x40 (device_mode_status) information to determine if the device is in tablet mode or not. hp_wmi_hw_state function was split into two functions; hp_wmi_get_dock_state and hp_wmi_get_tablet_mode. The new functions separate how dock_state and tablet_mode is handled in a cleaner manner. All changes were validated on a HP ZBook Workstation notebook, HP EliteBook x360, and HP EliteBook 850 G8. Signed-off-by:
-
Jorge Lopez authored
The purpose of this patch is to introduce a fix to hp_wmi_read_int() and eliminate failure error (0x05). Several WMI queries leverage hp_wmi_read_int() to read their data and were failing with error 0x05. HPWMI_DISPLAY_QUERY HPWMI_HDDTEMP_QUERY HPWMI_ALS_QUERY HPWMI_HARDWARE_QUERY HPWMI_WIRELESS_QUERY HPWMI_POSTCODEERROR_QUERY The failure occurs because hp_wmi_read_int() calls hp_wmi_perform_query() with input parameter of size greater than zero. Invoking those WMI commands with an input buffer size greater than zero causes the command to be rejected and error 0x05 be returned. All changes were validated on a HP ZBook Workstation notebook, HP EliteBook x360, and HP EliteBook 850 G8. Signed-off-by:
-
- 10 Mar, 2022 1 commit
-
-
Mario Limonciello authored
Currently the only way to discover if a system went into the deepest sleep state is to read from sysfs after you finished suspend. To better illustrate to users that problems have occurred, check as part of resume and display a warning. Signed-off-by:
-
- 09 Mar, 2022 4 commits
-
-
Hans de Goede authored
test_bit can only be used on longs not on ints, fix this. Reported-by:
Stephen Rothwell <sfr@canb.auug.org.au> Signed-off-by:
-
Hans de Goede authored
err is always set because if we get here then dytc_profile_available is always one of DYTC_FUNCMODE_MMC or DYTC_FUNCMODE_PSC, but the compiler cannot now that, so initialize err to 0 to avoid a compiler warning about err being uninitialized. Reported-by:
kernel test robot <lkp@intel.com> Signed-off-by:
-
Mark Pearson authored
Minor update cleaning up the code around convert_profile_to_dytc as identified in the previous commit. Signed-off-by:
-
Hans de Goede authored
The recently added support for Lenovo Yoga Tablet 2 tablets uses symbols from EFI and SPI add "depends on EFI && SPI" to the X86_ANDROID_TABLETS Kconfig entry. Reported-by:
Randy Dunlap <rdunlap@infradead.org> Signed-off-by:
-
- 08 Mar, 2022 3 commits
-
-
Dan Carpenter authored
The "size" variable can be uninitialized if amd_pmc_send_cmd() fails. Fixes: 3d7d407d ("platform/x86: amd-pmc: Add support for AMD Spill to DRAM STB feature") Signed-off-by:
Dan Carpenter <dan.carpenter@oracle.com> Link: https://lore.kernel.org/r/20220307141832.GA19660@kiliSigned-off-by:
-
Dan Carpenter authored
Currently the uncore_freq_common_init() return one on success and zero on failure. There is only one caller and it has a "forgot to set the error code" bug. Change uncore_freq_common_init() to return negative error codes which makes the code simpler and avoids this kind of bug in the future. Fixes: dbce412a ("platform/x86/intel-uncore-freq: Split common and enumeration part") Signed-off-by:
Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Link: https://lore.kernel.org/r/20220304131925.GG28739@kiliReviewed-by:
-
Jia-Ju Bai authored
The function device_create_file() in huawei_wmi_battery_add() can fail, so its return value should be checked. Fixes: 355a070b ("platform/x86: huawei-wmi: Add battery charging thresholds") Reported-by:
TOTE Robot <oslab@tsinghua.edu.cn> Signed-off-by:
Jia-Ju Bai <baijiaju1990@gmail.com> Link: https://lore.kernel.org/r/20220303022421.313-1-baijiaju1990@gmail.comReviewed-by:
-
- 02 Mar, 2022 15 commits
-
-
Mark Pearson authored
The Lenovo AMD platforms use PSC mode for providing platform profile support. Detect if PSC mode is available and add support for setting the different profile modes appropriately. Note - if both MMC mode and PSC mode are available then MMC mode will be used in preference. Tested on T14 G1 AMD and T14s G2 AMD. Signed-off-by:
-
David E. Box authored
Tests file configuration and error handling of the Intel Software Defined Silicon sysfs ABI. Signed-off-by:
David E. Box <david.e.box@linux.intel.com> Link: https://lore.kernel.org/r/20220225012457.1661574-2-david.e.box@linux.intel.comReviewed-by:
-
David E. Box authored
Add tool for key certificate and activation payload provisioning on Intel CPUs supporting Software Defined Silicon (SDSi). Signed-off-by:
-
Hans de Goede authored
The Surface 3 buttons are now handled by the generic soc_button_array driver. As part of adding support to soc_button_array the ACPI code now instantiates a platform_device rather then an i2c_client so there no longer is an i2c_client for this driver to bind to. Signed-off-by:
Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://lore.kernel.org/r/20220224110241.9613-3-hdegoede@redhat.com
-
Hans de Goede authored
The drivers/platform/surface/surface3_button.c code is alsmost a 1:1 copy of the soc_button_array code. The only big difference is that it binds to an i2c_client rather then to a platform_device. The cause of this is the ACPI resources for the MSHW0028 device containing a bogus I2cSerialBusV2 resource which causes the kernel to instantiate an i2c_client for it instead of a platform_device. Add "MSHW0028" to the ignore_serial_bus_ids[] list in drivers/apci/scan.c, so that a platform_device will be instantiated and add support for the MSHW0028 HID to soc_button_array. This fully replaces surface3_button, which will be removed in a separate commit (since it binds to the now no longer created i2c_client it no longer does anyyhing after this commit). Note the MSHW0028 id is used by Microsoft to describe the tablet buttons on both the Surface 3 and the Surface 3 Pro and the actual API/implementation for the Surface 3 Pro is quite different. The changes in this commit should not impact the separate surfacepro3_button driver: 1. Because of the bogus I2cSerialBusV2 resource problem that driver binds to the acpi_device itself, so instantiating a platform_device instead of an i2c_client does not matter. 2. The soc_button_array driver will not bind to the MSHW0028 device on the Surface 3 Pro, because it has no GPIO resources. Signed-off-by:
Dmitry Torokhov <dmitry.torokhov@gmail.com> Link: https://lore.kernel.org/r/20220224110241.9613-2-hdegoede@redhat.com
-
Hans de Goede authored
The ACPI tables for the codec setup on the Lenovo Yoga Tablet 2 830/1050 miss 2 things compared to their Windows (Lenovo Yoga Tablet 2 1051) counterparts: 1. There is no CLKE ACPI method to enable output of the 32KHz PMU clock on pin 6 of the SUS GPIO controller 2. The GPIOs used by the codec are not listed in the fwnode for the codec Add pinctrl code to set the SUS6 pin mux manually and a gpio-lookup table for the GPIOs to work around both issues. Signed-off-by:
-
Hans de Goede authored
These tablets' DSDT does not set acpi_gbl_reduced_hardware, so acpi_power_off gets used as pm_power_off handler. Not setting acpi_gbl_reduced_hardware may very well be correct for these tablets, but acpi_power_off is broken on them. Using acpi_power_off causes "poweroff" to hang hard. Requiring pressing the powerbutton for 30 seconds *twice* followed by a normal 3 second press to recover. Avoid this by overriding the global pm_power_off handler to do an EFI poweroff, which does work, instead. Signed-off-by:
-
Hans de Goede authored
The Lenovo Yoga Tablet 2 series comes in 4 versions: 830F, 830L, 1050F and 1050L. The F postfix indicates a wifi only version and the L postfix indicates a LTE version. The 830 models are 8" and the 1050 models are 10". Despite there being 8" and 10" versions all models use the same mainboard, with an identical BIOS and thus identical DMI strings, so support for all 4 models is added through a single DMI table entry. As all devices dealt with in the x86-android-tablets modules, these are x86 ACPI tablets which ships with Android x86 as factory OS. The mainboard's DSDT contain a bunch of I2C devices which are not actually there, causing various resource conflicts. Enumeration of these is skipped through the acpi_quirk_skip_i2c_client_enumeration(). Add support for manually instantiating the I2C devices which are actually present on this tablet by adding the necessary device info to the x86-android-tablets module. This has been tested on a 830F and a 1050L tablet. Signed-off-by:
-
Hans de Goede authored
Sometimes IRQs used by GPIOs in direct-IRQ mode are already registered because they are used as ACPI "Interrupt () {}" resource for one of the many bogus I2C devices present in the broken DSDTs of Android x86 tablets. This is an issue if the existing (bogus) ACPI resource uses different trigger settings then what is being requested, leading to an -EBUSY error return of acpi_register_gsi(). Fix this by calling acpi_unregister_gsi() first, so that the acpi_register_gsi() is allowed to change the trigger settings. In cases where the GSI has not been registered yet the acpi_unregister_gsi() is a no-op. Signed-off-by: -
Hans de Goede authored
-
Mark Pearson authored
Instead of having quirks for systems that have a second fan it would be nice to detect this setup. Unfortunately, confirmed by the Lenovo FW team, there is no way to retrieve this information from the EC or BIOS. Recommendation was to attempt to read the fan and if successful then assume a 2nd fan is present. The fans are also supposed to spin up on boot for some time, so in theory we could check for a speed > 0. In testing this seems to hold true but as I couldn't test on all platforms I've avoided implementing this. It also breaks for the corner case where you load the module once the fans are idle. Tested on P1G4, P1G3, X1C9 and T14 (no fans) and it works correctly. For the platforms with dual fans where it was confirmed to work I have removed the quirks. Potentially this could be done for all platforms but I've left untested platforms in for now. On these platforms the fans will be enabled and then detected - so no impact. Signed-off-by:
-
Naveen Krishna Chatradhi authored
This documentation for amd_hsmp driver explains how to use the device interface. Signed-off-by:
Naveen Krishna Chatradhi <nchatrad@amd.com> Acked-by:
Song Liu <song@kernel.org> Link: https://lore.kernel.org/r/20220222050501.18789-2-nchatrad@amd.comReviewed-by:
-
Suma Hegde authored
Recent Fam19h EPYC server line of processors from AMD support system management functionality via HSMP (Host System Management Port) interface. The Host System Management Port (HSMP) is an interface to provide OS-level software with access to system management functions via a set of mailbox registers. More details on the interface can be found in chapter "7 Host System Management Port (HSMP)" of the following PPR https://www.amd.com/system/files/TechDocs/55898_B1_pub_0.50.zip This patch adds new amd_hsmp module under the drivers/platforms/x86/ which creates miscdevice with an IOCTL interface to the user space. /dev/hsmp is for running the hsmp mailbox commands. Signed-off-by:
Suma Hegde <suma.hegde@amd.com> Signed-off-by:
Carlos Bilbao <carlos.bilbao@amd.com> Acked-by:
Nathan Fontenot <nathan.fontenot@amd.com> Link: https://lore.kernel.org/r/20220222050501.18789-1-nchatrad@amd.comReviewed-by:
-
Hans de Goede authored
The battery on the 2nd hand Surface 3 which I recently bought appears to not have a serial number programmed in. This results in any I2C reads from the registers containing the serial number failing with an I2C NACK. This was causing mshw0011_bix() to fail causing the battery readings to not work at all. Ignore EREMOTEIO (I2C NACK) errors when retrieving the serial number and continue with an empty serial number to fix this. Fixes: b1f81b49 ("platform/x86: surface3_power: MSHW0011 rev-eng implementation") BugLink: https://github.com/linux-surface/linux-surface/issues/608Reviewed-by:
Benjamin Tissoires <benjamin.tissoires@redhat.com> Reviewed-by:
Maximilian Luz <luzmaximilian@gmail.com> Signed-off-by:
-
Mario Limonciello authored
commit 59348401 ("platform/x86: amd-pmc: Add special handling for timer based S0i3 wakeup") adds support for using another platform timer in lieu of the RTC which doesn't work properly on some systems. This path was validated and worked well before submission. During the 5.16-rc1 merge window other patches were merged that caused this to stop working properly. When this feature was used with 5.16-rc1 or later some OEM laptops with the matching firmware requirements from that commit would shutdown instead of program a timer based wakeup. This was bisected to commit 8d89835b ("PM: suspend: Do not pause cpuidle in the suspend-to-idle path"). This wasn't supposed to cause any negative impacts and also tested well on both Intel and ARM platforms. However this changed the semantics of when CPUs are allowed to be in the deepest state. For the AMD systems in question it appears this causes a firmware crash for timer based wakeup. It's hypothesized to be caused by the `amd-pmc` driver sending `OS_HINT` and all the CPUs going into a deep state while the timer is still being programmed. It's likely a firmware bug, but to avoid it don't allow setting CPUs into the deepest state while using CZN timer wakeup path. If later it's discovered that this also occurs from "regular" suspends without a timer as well or on other silicon, this may be later expanded to run in the suspend path for more scenarios. Cc: stable@vger.kernel.org # 5.16+ Suggested-by:
-
- 24 Feb, 2022 1 commit
-
-
Hans de Goede authored
On the Lenovo Yoga Tablet 2 830 / 1050 / 1051 models the 32KHz PMU clk, which can be muxed externally to SUS pin 5 and/or 6 is used as a clock for the audio codec. On the 830 and 1050 models, with ship with Android as factory OS the pin-muxing for this is not setup by the BIOS. Add a pinconf group + function for the pmu_clk on SUS pin 5 and 6 to allow setting the pinmux up from within the x86-android-tablets platform code. Signed-off-by:
-
- 23 Feb, 2022 1 commit
-
-
Matan Ziv-Av authored
For now leave also the driver specific location, with deprecated warning in documentation. Signed-off-by:
Matan Ziv-Av <matan@svgalib.org> Link: https://lore.kernel.org/r/eca2fa354f60b8a6e5a5c9c8e244fea56616970a.1645278914.git.matan@svgalib.orgReviewed-by:
-
- 21 Feb, 2022 1 commit
-
-
Daniel Scally authored
Without the terminator, if a con_id is passed to gpio_find() that does not exist in the lookup table the function will not stop looping correctly, and eventually cause an oops. Fixes: 19d8d6e3 ("platform/x86: int3472: Pass tps68470_regulator_platform_data to the tps68470-regulator MFD-cell") Signed-off-by:
Daniel Scally <djrscally@gmail.com> Link: https://lore.kernel.org/r/20220216225304.53911-5-djrscally@gmail.comReviewed-by:
-
- 17 Feb, 2022 1 commit
-
-
Mateusz Jończyk authored
The declaration EXPORT_SYMBOL(dcdbas_smi_request); was placed after smi_request_store(), which made a false impression that dcdbas_smi_request() was not exported. Signed-off-by:Mateusz Jończyk <mat.jonczyk@o2.pl> Cc: Stuart Hayes <stuart.w.hayes@gmail.com> Cc: Hans de Goede <hdegoede@redhat.com> Cc: Mark Gross <markgross@kernel.org> Link: https://lore.kernel.org/r/20220212125908.357588-1-mat.jonczyk@o2.plSigned-off-by:
-
