- 02 Mar, 2022 13 commits
-
-
David E. Box authored
Add tool for key certificate and activation payload provisioning on Intel CPUs supporting Software Defined Silicon (SDSi). Signed-off-by:
David E. Box <david.e.box@linux.intel.com> Link: https://lore.kernel.org/r/20220225012457.1661574-1-david.e.box@linux.intel.comReviewed-by:
Hans de Goede <hdegoede@redhat.com> 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:
Rafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-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:
Mark Pearson <markpearson@lenovo.com> Link: https://lore.kernel.org/r/20220222185137.4325-1-markpearson@lenovo.comReviewed-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:
Mario Limonciello <mario.limonciello@amd.com> Link: https://lore.kernel.org/r/20220223175237.6209-1-mario.limonciello@amd.comReviewed-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 6 commits
-
-
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:
-
Sanket Goswami authored
Spill to DRAM functionality is a feature that allows STB (Smart Trace Buffer) to spill data from SRAM into DRAM on some future AMD ASICs. The size allocated for STB is more than the earlier SoC's which helps to collect more tracing and telemetry data. Co-developed-by:
Shyam Sundar S K <Shyam-sundar.S-k@amd.com> Signed-off-by:
Sanket Goswami <Sanket.Goswami@amd.com> Reviewed-by:
-
Srinivas Pandruvada authored
Split the current driver in two parts: - Common part: All the commom function other than enumeration function. - Enumeration/HW specific part: The current enumeration using CPU model is left in the old module. This uses service of common driver to register sysfs objects. Also provide callbacks for MSR access related to uncore. - Add MODULE_DEVICE_TABLE to uncore-frequency.c No functional changes are expected. Signed-off-by:
Srinivas Pandruvada <srinivas.pandruvada@intel.com> Acked-by:
-
Srinivas Pandruvada authored
Add a new sysfs attribute "current_freq_khz" to display current uncore frequency. This value is read from MSR 0x621. Root user permission is required to read uncore current frequency. Signed-off-by:
-
Srinivas Pandruvada authored
Use of sysfs API is always preferable over using kobject calls to create attributes. Remove usage of kobject_init_and_add() and use sysfs_create_group(). To create relationship between sysfs attribute and uncore instance use device_attribute*, which is defined per uncore instance. To create uniform locking for both read and write attributes take lock in the sysfs callbacks, not in the actual functions where the MSRs are read or updated. No functional changes are expected. Signed-off-by:
-
Srinivas Pandruvada authored
Move the current driver from platform/x86/intel/uncore-frequency.c to platform/x86/intel/uncore-frequency/uncore-frequency.c. No functional changes are expected. Signed-off-by:
-
- 14 Feb, 2022 1 commit
-
-
David E. Box authored
Intel Software Defined Silicon (SDSi) is a post manufacturing mechanism for activating additional silicon features. Features are enabled through a license activation process. The SDSi driver provides a per socket, sysfs attribute interface for applications to perform 3 main provisioning functions: 1. Provision an Authentication Key Certificate (AKC), a key written to internal NVRAM that is used to authenticate a capability specific activation payload. 2. Provision a Capability Activation Payload (CAP), a token authenticated using the AKC and applied to the CPU configuration to activate a new feature. 3. Read the SDSi State Certificate, containing the CPU configuration state. The operations perform function specific mailbox commands that forward the requests to SDSi hardware to perform authentication of the payloads and enable the silicon configuration (to be made available after power cycling). The SDSi device itself is enumerated as an auxiliary device from the intel_vsec driver and as such has a build dependency on CONFIG_INTEL_VSEC. Link: https://github.com/intel/intel-sdsiSigned-off-by:
Mark Gross <markgross@kernel.org> Link: https://lore.kernel.org/r/20220212013252.1293396-2-david.e.box@linux.intel.comReviewed-by:
-
- 11 Feb, 2022 10 commits
-
-
Hans de Goede authored
Now that there is only 1 c-file left of the intel_cht_int33fe code, move it to the intel directory instead of it having its own int33fe sub-directory. Note this also renames the module from intel_cht_int33fe_typec to intel_chtwc_int33fe, to better match the names of other PMIC related modules like the intel_chtdc_ti_pwrbtn module. Signed-off-by:
-
Hans de Goede authored
Move the Lenovo Yogabook YB1-X9x fuel-gauge instantiation code over to the x86-android-tablets module, which already deals with this for various other devices. This removes the need to have a special intel_cht_int33fe_microb module just for Lenovo Yogabook YB1-X9x laptops. Signed-off-by:
-
Hans de Goede authored
The intel_cht_int33fe driver is intended to deal with ACPI INT33FE firmware-nodes on Cherry Trail devices with a Whiskey Cove PMIC. The original version of the driver only dealt with the GPD win and GPD pocket boards where the WC PMIC is connected to a TI BQ24292i charger, paired with a Maxim MAX17047 fuelgauge + a FUSB302 USB Type-C Controller + a PI3USB30532 USB switch, for a fully functional Type-C port. Later it was split into a Type-C and a Micro-B variant to deal with the Lenovo Yoga Book YB1-X90 / Lenovo Yoga Book YB1-X91 boards where the ACPI INT33FE firmware-node only describes the TI BQ27542 fuelgauge. Currently the driver differentiates between these 2 models by counting the number of I2cSerialBus resources in the firmware-node. There are a number of problems with this approach: 1. The driver autoloads based on the acpi:INT33FE modalias causing it to get loaded on almost all Bay Trail and Cherry Trail devices. It checks for the presence of a WC PMIC, so it won't bind but the loading still wastes time and memory. 2. Both code paths in the driver are really only designed for a single board and have harcoded various assumptions about these boards, if another design matching the current checks ever shows up the driver may end up doing something completely wrong. Avoid both issues by switching to using DMI based autoloading of the module, which has neither of these problems. Note this splits the previous intel_cht_int33fe kernel module into two modules: intel_cht_int33fe_typec and intel_cht_int33fe_microb, one for each model. Signed-off-by:
-
Hans de Goede authored
Minor charger / fuel-gauge improvements: 1. Make some of the names of charger / fuel-gauge related globals more generic in preparation for also using them on other boards. 2. Update the dev_name on the Asus ME176C and TF103C to reflect that these are using the bq24297 variant of the bq24190 family. 3. During review of the ug3105 driver the "upi,rsns-microohm" property was renamed to "upisemi,rsns-microohm" as "upisemi" is the correct vendor prefix, update the ug3105 properties accordingly. Signed-off-by:
-
Hans de Goede authored
The Nextbook Ares 8 is a x86 ACPI tablet which ships with Android x86 as factory OS. Its DSDT contains 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. Signed-off-by:
Andy Shevchenko <andy.shevchenko@gmail.com> Link: https://lore.kernel.org/r/20220205191356.225505-6-hdegoede@redhat.com
-
Hans de Goede authored
Add the IRQ for the accelerometer to the Asus ME176C board info. Signed-off-by:
-
Hans de Goede authored
The Asus ME176C + TF103C both have a lid-switch (for a cover in the ME176C case), add a gpio-keys platform-device and platform-data describing the lid-switch on both. Note the "intel-int3496" in the asus_me176c_tf103c_pdevs[] array is not new / not a change. This was already present in the generic int3496_pdevs[] array, to which pdev_info pointed before. The int3496_pdevs[] array contains just this entry for boards which only need that single pdev. Signed-off-by:
-
Hans de Goede authored
Factor the code to go from a gpiochip label + pin-numer to a gpio_desc out of x86_acpi_irq_helper_get() and make it into a new x86_android_tablet_get_gpiod() helper, as this will be necessary in some x86_dev_info.init() functions too. Signed-off-by:
-
Hans de Goede authored
Add properties describing the battery on the Asus ME176C / TF103C tablets. The max constant charge volt / current settings were taken from the factory Android image on these tablets. Signed-off-by:
-
Hans de Goede authored
power_supply_get_battery_info() which is used by charger and fuel-gauge drivers on x86-android-tablets, expects the battery properties to be described in a stand-alone battery fwnode which is then referenced from both the charger and fuel-gauge device's fwnodes. Add support for registering + unregistering a swnode for this. Signed-off-by:
-
- 05 Feb, 2022 1 commit
-
-
Hans de Goede authored
The fan curve control patches introduced a regression for at least the TUF FX506 and possibly other TUF series laptops that do not have support for fan curve control. As part of the probing process, asus_wmi_evaluate_method_buf is called to get the factory default fan curve . The WMI management function returns 0 on certain laptops to indicate lack of fan curve control instead of ASUS_WMI_UNSUPPORTED_METHOD. This 0 is transformed to -ENODATA which results in failure when probing. Fixes: 0f0ac158 ("platform/x86: asus-wmi: Add support for custom fan curves") Reported-and-tested-by:
Abhijeet V <abhijeetviswa@gmail.com> Signed-off-by:
-
- 03 Feb, 2022 4 commits
-
-
Christophe JAILLET authored
's3_wmi.input' is a managed resource, so there should be no need to free it explicitly. Moreover, 's3_wmi' is a global variable. 's3_wmi.input' should be NULL when this error handling path is executed, because it has not been assigned yet. All this is puzzling. So simplify it and remove a few lines of code to have it be more straightforward. Fixes: 3dda3b37 ("platform/x86: Add custom surface3 platform device for controlling LID") Signed-off-by:
Christophe JAILLET <christophe.jaillet@wanadoo.fr> Reviewed-by:
-
Rafael J. Wysocki authored
Replace acpi_bus_get_device() that is going to be dropped with acpi_fetch_acpi_dev(). No intentional functional impact. Signed-off-by:
-
Rafael J. Wysocki authored
Replace acpi_bus_get_device() that is going to be dropped with acpi_fetch_acpi_dev(). No intentional functional impact. Signed-off-by:
-
Hans de Goede authored
The ThinkPad T15g Gen 2 has 2 fan, add a TPACPI_FAN_2CTL quirk entry for it to the fan_quirk_table[] so that both fans can be controllerd. Reported-and-tested-by:
David Dreschner <david@dreschner.net> Signed-off-by:
-
- 02 Feb, 2022 2 commits
-
-
Hans de Goede authored
This branch contains 5.17-rc1 + the SPI tree's spi-acpi-helpers tag + the other patches from the "[PATCH v6 0/9] Support Spi in i2c-multi-instantiate driver" series.
-
Lucas Tanure authored
The ACPI device with CSC3551 or CLSA0100 are sound cards with multiple instances of CS35L41 connected by I2C or SPI to the main CPU. We add an ID to the ignore_serial_bus_ids list to enumerate all I2C or SPI devices correctly. The same IDs are also added into serial-multi-instantiate so that the driver can correctly enumerate the ACPI. Signed-off-by:
Lucas Tanure <tanureal@opensource.cirrus.com> Signed-off-by:
Stefan Binding <sbinding@opensource.cirrus.com> Link: https://lore.kernel.org/r/20220121172431.6876-10-sbinding@opensource.cirrus.comReviewed-by:
-
