platform/x86: amd-pmc: Move to later in the suspend process
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.
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.
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.
Enver Balalic [Mon, 14 Mar 2022 12:14:53 +0000 (13:14 +0100)]
platform/x86: hp-wmi: support omen thermal profile policy v1
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.
Jorge Lopez [Thu, 10 Mar 2022 21:08:53 +0000 (15:08 -0600)]
platform/x86: hp-wmi: Changing bios_args.data to be dynamically allocated
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.
Jorge Lopez [Thu, 10 Mar 2022 21:08:52 +0000 (15:08 -0600)]
platform/x86: hp-wmi: Fix 0x05 error code reported by several WMI calls
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.
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.
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.
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.
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.
Hans de Goede [Wed, 9 Mar 2022 17:05:31 +0000 (18:05 +0100)]
platform/x86: thinkpad_acpi: Fix compiler warning about uninitialized err variable
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.
Hans de Goede [Tue, 8 Mar 2022 15:29:42 +0000 (16:29 +0100)]
platform/x86: x86-android-tablets: Depend on EFI and SPI
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.
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.
Hans de Goede [Thu, 24 Feb 2022 11:02:41 +0000 (12:02 +0100)]
platform/surface: Remove Surface 3 Button driver
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.
Hans de Goede [Thu, 24 Feb 2022 11:02:40 +0000 (12:02 +0100)]
Input: soc_button_array - add support for Microsoft Surface 3 (MSHW0028) buttons
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.
Hans de Goede [Wed, 23 Feb 2022 13:31:53 +0000 (14:31 +0100)]
platform/x86: x86-android-tablets: Lenovo Yoga Tablet 2 830/1050 sound support
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.
Hans de Goede [Wed, 23 Feb 2022 13:31:52 +0000 (14:31 +0100)]
platform/x86: x86-android-tablets: Workaround Lenovo Yoga Tablet 2 830/1050 poweroff hang
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.
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.
Hans de Goede [Wed, 23 Feb 2022 13:31:50 +0000 (14:31 +0100)]
platform/x86: x86-android-tablets: Fix EBUSY error when requesting IOAPIC IRQs
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.
Mark Pearson [Tue, 22 Feb 2022 18:51:37 +0000 (13:51 -0500)]
platform/x86: thinkpad_acpi: Add dual fan probe
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.
Suma Hegde [Tue, 22 Feb 2022 05:05:00 +0000 (10:35 +0530)]
platform/x86: Add AMD system management interface
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.
Hans de Goede [Thu, 24 Feb 2022 10:18:48 +0000 (11:18 +0100)]
surface: surface3_power: Fix battery readings on batteries without a serial number
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.
platform/x86: amd-pmc: Set QOS during suspend on CZN w/ timer wakeup
commit 59348401ebed ("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 8d89835b0467 ("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.
Hans de Goede [Wed, 23 Feb 2022 13:31:49 +0000 (14:31 +0100)]
pinctrl: baytrail: Add pinconf group + function for the pmu_clk
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.
Daniel Scally [Wed, 16 Feb 2022 22:53:02 +0000 (22:53 +0000)]
platform/x86: int3472: Add terminator to gpiod_lookup_table
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.
Mateusz Jończyk [Sat, 12 Feb 2022 12:59:08 +0000 (13:59 +0100)]
platform/dcdbas: move EXPORT_SYMBOL after function
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.
Sanket Goswami [Fri, 4 Feb 2022 12:25:27 +0000 (17:55 +0530)]
platform/x86: amd-pmc: Add support for AMD Spill to DRAM STB feature
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.
platform/x86/intel-uncore-freq: Split common and enumeration part
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
platform/x86/intel/uncore-freq: Use sysfs API to create attributes
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.
David E. Box [Sat, 12 Feb 2022 01:32:50 +0000 (17:32 -0800)]
platform/x86: Add Intel Software Defined Silicon driver
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.
Hans de Goede [Sun, 6 Feb 2022 22:02:20 +0000 (23:02 +0100)]
platform/x86: intel_cht_int33fe: Move to intel directory
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.
Hans de Goede [Sun, 6 Feb 2022 22:02:19 +0000 (23:02 +0100)]
platform/x86: intel_cht_int33fe: Drop Lenovo Yogabook YB1-X9x code
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.
Hans de Goede [Sun, 6 Feb 2022 22:02:18 +0000 (23:02 +0100)]
platform/x86: intel_cht_int33fe: Switch to DMI modalias based loading
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.
Hans de Goede [Sun, 6 Feb 2022 22:02:17 +0000 (23:02 +0100)]
platform/x86: x86-android-tablets: Minor charger / fuel-gauge improvements
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.
Hans de Goede [Sat, 5 Feb 2022 19:13:56 +0000 (20:13 +0100)]
platform/x86: x86-android-tablets: Add Nextbook Ares 8 data
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.
Hans de Goede [Sat, 5 Feb 2022 19:13:54 +0000 (20:13 +0100)]
platform/x86: x86-android-tablets: Add lid-switch gpio-keys pdev to Asus ME176C + TF103C
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.
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.
Hans de Goede [Sat, 5 Feb 2022 19:13:52 +0000 (20:13 +0100)]
platform/x86: x86-android-tablets: Add Asus ME176C/TF103C charger and fuelgauge props
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.
Hans de Goede [Sat, 5 Feb 2022 19:13:51 +0000 (20:13 +0100)]
platform/x86: x86-android-tablets: Add battery swnode support
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.
Hans de Goede [Sat, 5 Feb 2022 11:28:40 +0000 (12:28 +0100)]
platform/x86: asus-wmi: Fix regression when probing for fan curve control
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.
'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.
Hans de Goede [Wed, 2 Feb 2022 17:29:59 +0000 (18:29 +0100)]
Merge tag 'platform-drivers-x86-serial-multi-instantiate-1' into review-hans
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.
Stefan Binding [Fri, 21 Jan 2022 17:24:29 +0000 (17:24 +0000)]
platform/x86: serial-multi-instantiate: Add SPI support
Add support for spi bus in serial-multi-instantiate driver
Some peripherals can have either a I2C or a SPI connection
to the host (but not both) but use the same HID for both
types. So it is not possible to use the HID to determine
whether it is I2C or SPI. The driver must check the node
to see if it contains I2cSerialBus or SpiSerialBus entries.
For backwards-compatibility with the existing nodes I2C is
checked first and if such entries are found ONLY I2C devices
are created. Since some existing nodes that were already
handled by this driver could also contain unrelated
SpiSerialBus nodes that were previously ignored, and this
preserves that behavior. If there is ever a need to handle
a node where both I2C and SPI devices must be instantiated
this can be added in future.
Reorganize I2C functions to accommodate SPI support
Split the probe and factor out parts of the code
that will be used in the SPI support
Also switched from strlcpy() to strscpy()
Mark Pearson [Thu, 27 Jan 2022 19:03:58 +0000 (14:03 -0500)]
platform/x86: thinkpad_acpi: Fix incorrect use of platform profile on AMD platforms
Lenovo AMD based platforms have been offering platform_profiles but they
are not working correctly. This is because the mode we are using on the
Intel platforms (MMC) is not available on the AMD platforms.
This commit adds checking of the functional capabilities returned by the
BIOS to confirm if MMC is supported or not. Profiles will not be
available if the platform is not MMC capable.
I'm investigating and working on an alternative for AMD platforms but
that is still work-in-progress.
platform/x86: amd-pmc: Correct usage of SMU version
Yellow carp has been outputting versions like `1093.24.0`, but this
is supposed to be 69.24.0. That is the MSB is being interpreted
incorrectly.
The MSB is not part of the major version, but has generally been
treated that way thus far. It's actually the program, and used to
distinguish between two programs from a similar family but different
codebase.
The call sequence suggested that misc_device /dev file can be opened
before misc device is yet to be registered, which is done only once.
Here punit_misc_dev_lock was used as common lock, to protect the
registration by multiple ISST HW drivers, one time setup, prevent
duplicate registry of misc device and prevent load/unload when device
is open.
We can split into locks:
- One which just prevent duplicate call to misc_register() and one
time setup. Also never call again if the misc_register() failed or
required one time setup is failed. This lock is not shared with
any misc device callbacks.
- The other lock protects registry, load and unload of HW drivers.
Sequence in isst_if_cdev_register()
- Register callbacks under punit_misc_dev_open_lock
- Call isst_misc_reg() which registers misc_device on the first
registry which is under punit_misc_dev_reg_lock, which is not
shared with callbacks.
Sequence in isst_if_cdev_unregister
Just opposite of isst_if_cdev_register
The driver as originally submitted accidentally relied on Android having
run before and Android having unmasked the 2nd level IRQ-mask for the
charger IRQ. This worked since these are PMIC registers which are only
reset when the battery is fully drained or disconnected.
Fix the charger IRQ no longer working after loss of battery power by
properly setting the 2nd level IRQ-mask for the charger IRQ.
Note this removes the need to enable/disable our parent IRQ which just
sets the mask bit in the 1st level IRQ-mask register, setting one of
the 2 level masks is enough to stop the IRQ from getting reported.
Alexander Kobel [Wed, 12 Jan 2022 11:18:27 +0000 (12:18 +0100)]
platform/x86: thinkpad_acpi: Add quirk for ThinkPads without a fan
Some ThinkPad models, like the X1 Tablet 1st and 2nd Gen, are passively
cooled without any fan. Currently, an entry in /proc/acpi/ibm/fan is
nevertheless created, and misleadingly shows
status: enabled
speed: 65535
level: auto
This patch adds a TPACPI_FAN_NOFAN quirk definition and corresponding
handling to not initialize a fan interface at all.
For the time being, the quirk is only applied for X1 Tablet 2nd Gen
(types 20JB, 20JC; EC N1O...); further models (such as Gen1, types 20GG
and 20GH) can be added easily once tested.
Tested on a 20JCS00C00, BIOS N1OET58W (1.43), EC N1OHT34W.
Microsoft Surface platform-specific devices are only present on
Microsoft Surface platforms, which are currently limited to arm64 and
x86. Hence add a dependency on ARM64 || X86, to prevent asking the user
about drivers for these devices when configuring a kernel for an
architecture that does not support Microsoft Surface platforms.
Lubomir Rintel [Mon, 10 Jan 2022 06:35:12 +0000 (07:35 +0100)]
platform/x86: x86-android-tablets: Fix the buttons on CZC P10T tablet
This switches the P10T tablet to "Android" mode, where the Home button
sends a single sancode instead of a Windows-specific key combination and
the other button doesn't disable the Wi-Fi.
Hans de Goede [Mon, 10 Jan 2022 10:39:51 +0000 (11:39 +0100)]
platform/x86: x86-android-tablets: Add an init() callback to struct x86_dev_info
Add an init() callback to struct x86_dev_info, board descriptions can use
this to do some custom setup before registering the i2c_clients, platform-
devices and servdevs.
Also add an exit() callback to also allow for cleanup of the custom setup.
Hans de Goede [Mon, 10 Jan 2022 10:39:50 +0000 (11:39 +0100)]
platform/x86: x86-android-tablets: Add support for disabling ACPI _AEI handlers
Some of the broken DSDTs on these devices often also include broken / wrong
_AEI (ACPI Event Interrupt) handlers, which can cause e.g. interrupt storms
by listening to a floating GPIO pin.
Add support for disabling these and disable them on the Asus ME176C and
TF103C tablets.
Linus Torvalds [Sun, 23 Jan 2022 06:14:21 +0000 (08:14 +0200)]
Merge tag 'perf-tools-for-v5.17-2022-01-22' of git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux
Pull more perf tools updates from Arnaldo Carvalho de Melo:
- Fix printing 'phys_addr' in 'perf script'.
- Fix failure to add events with 'perf probe' in ppc64 due to not
removing leading dot (ppc64 ABIv1).
- Fix cpu_map__item() python binding building.
- Support event alias in form foo-bar-baz, add pmu-events and
parse-event tests for it.
- No need to setup affinities when starting a workload or attaching to
a pid.
- Use path__join() to compose a path instead of ad-hoc snprintf()
equivalent.
- Override attr->sample_period for non-libpfm4 events.
- Use libperf cpumap APIs instead of accessing the internal state
directly.
- Sync x86 arch prctl headers and files changed by the new
set_mempolicy_home_node syscall with the kernel sources.
- Remove duplicate include in cpumap.h.
- Remove redundant err variable.
* tag 'perf-tools-for-v5.17-2022-01-22' of git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux:
perf tools: Remove redundant err variable
perf test: Add parse-events test for aliases with hyphens
perf test: Add pmu-events test for aliases with hyphens
perf parse-events: Support event alias in form foo-bar-baz
perf evsel: Override attr->sample_period for non-libpfm4 events
perf cpumap: Remove duplicate include in cpumap.h
perf cpumap: Migrate to libperf cpumap api
perf python: Fix cpu_map__item() building
perf script: Fix printing 'phys_addr' failure issue
tools headers UAPI: Sync files changed by new set_mempolicy_home_node syscall
tools headers UAPI: Sync x86 arch prctl headers with the kernel sources
perf machine: Use path__join() to compose a path instead of snprintf(dir, '/', filename)
perf evlist: No need to setup affinities when disabling events for pid targets
perf evlist: No need to setup affinities when enabling events for pid targets
perf stat: No need to setup affinities when starting a workload
perf affinity: Allow passing a NULL arg to affinity__cleanup()
perf probe: Fix ppc64 'perf probe add events failed' case
Linus Torvalds [Sun, 23 Jan 2022 06:07:02 +0000 (08:07 +0200)]
Merge tag 'trace-v5.17-3' of git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace
Pull ftrace fix from Steven Rostedt:
"Fix s390 breakage from sorting mcount tables.
The latest merge of the tracing tree sorts the mcount table at build
time. But s390 appears to do things differently (like always) and
replaces the sorted table back to the original unsorted one. As the
ftrace algorithm depends on it being sorted, bad things happen when it
is not, and s390 experienced those bad things.
Add a new config to tell the boot if the mcount table is sorted or
not, and allow s390 to opt out of it"
* tag 'trace-v5.17-3' of git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace:
ftrace: Fix assuming build time sort works for s390
ftrace: Fix assuming build time sort works for s390
To speed up the boot process, as mcount_loc needs to be sorted for ftrace
to work properly, sorting it at build time is more efficient than boot up
and can save milliseconds of time. Unfortunately, this change broke s390
as it will modify the mcount_loc location after the sorting takes place
and will put back the unsorted locations. Since the sorting is skipped at
boot up if it is believed that it was sorted at run time, ftrace can crash
as its algorithms are dependent on the list being sorted.
Add a new config BUILDTIME_MCOUNT_SORT that is set when
BUILDTIME_TABLE_SORT but not if S390 is set. Use this config to determine
if sorting should take place at boot up.
Linus Torvalds [Sun, 23 Jan 2022 04:32:29 +0000 (06:32 +0200)]
Merge tag 'kbuild-fixes-v5.17' of git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild
Pull Kbuild fixes from Masahiro Yamada:
- Bring include/uapi/linux/nfc.h into the UAPI compile-test coverage
- Revert the workaround of CONFIG_CC_IMPLICIT_FALLTHROUGH
- Fix build errors in certs/Makefile
* tag 'kbuild-fixes-v5.17' of git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild:
certs: Fix build error when CONFIG_MODULE_SIG_KEY is empty
certs: Fix build error when CONFIG_MODULE_SIG_KEY is PKCS#11 URI
Revert "Makefile: Do not quote value for CONFIG_CC_IMPLICIT_FALLTHROUGH"
usr/include/Makefile: add linux/nfc.h to the compile-test coverage
Linus Torvalds [Sun, 23 Jan 2022 04:20:44 +0000 (06:20 +0200)]
Merge tag 'bitmap-5.17-rc1' of git://github.com/norov/linux
Pull bitmap updates from Yury Norov:
- introduce for_each_set_bitrange()
- use find_first_*_bit() instead of find_next_*_bit() where possible
- unify for_each_bit() macros
* tag 'bitmap-5.17-rc1' of git://github.com/norov/linux:
vsprintf: rework bitmap_list_string
lib: bitmap: add performance test for bitmap_print_to_pagebuf
bitmap: unify find_bit operations
mm/percpu: micro-optimize pcpu_is_populated()
Replace for_each_*_bit_from() with for_each_*_bit() where appropriate
find: micro-optimize for_each_{set,clear}_bit()
include/linux: move for_each_bit() macros from bitops.h to find.h
cpumask: replace cpumask_next_* with cpumask_first_* where appropriate
tools: sync tools/bitmap with mother linux
all: replace find_next{,_zero}_bit with find_first{,_zero}_bit where appropriate
cpumask: use find_first_and_bit()
lib: add find_first_and_bit()
arch: remove GENERIC_FIND_FIRST_BIT entirely
include: move find.h from asm_generic to linux
bitops: move find_bit_*_le functions from le.h to find.h
bitops: protect find_first_{,zero}_bit properly
John Garry [Mon, 17 Jan 2022 15:10:14 +0000 (23:10 +0800)]
perf test: Add pmu-events test for aliases with hyphens
Add a test for aliases with hyphens in the name to ensure that the
pmu-events tables are as expects. There should be no reason why these sort
of aliases would be treated differently, but no harm in checking.
John Garry [Mon, 17 Jan 2022 15:10:13 +0000 (23:10 +0800)]
perf parse-events: Support event alias in form foo-bar-baz
Event aliasing for events whose name in the form foo-bar-baz is not
supported, while foo-bar, foo_bar_baz, and other combinations are, i.e.
two hyphens are not supported.
The HiSilicon D06 platform has events in such form:
German Gomez [Tue, 18 Jan 2022 14:40:54 +0000 (14:40 +0000)]
perf evsel: Override attr->sample_period for non-libpfm4 events
A previous patch preventing "attr->sample_period" values from being
overridden in pfm events changed a related behaviour in arm-spe.
Before said patch:
perf record -c 10000 -e arm_spe_0// -- sleep 1
Would yield an SPE event with period=10000. After the patch, the period
in "-c 10000" was being ignored because the arm-spe code initializes
sample_period to a non-zero value.
This patch restores the previous behaviour for non-libpfm4 events.
Ian Rogers [Sat, 22 Jan 2022 04:58:10 +0000 (20:58 -0800)]
perf cpumap: Migrate to libperf cpumap api
Switch from directly accessing the perf_cpu_map to using the appropriate
libperf API when possible. Using the API simplifies the job of
refactoring use of perf_cpu_map.
Perf script was failed to print the phys_addr for SPE profiling.
One 'dummy' event is added by SPE profiling but it doesn't have PHYS_ADDR
attribute set, perf script then exits with error.
Now referring to 'addr', use evsel__do_check_stype() to check the type.
Before:
# perf record -e arm_spe_0/branch_filter=0,ts_enable=1,pa_enable=1,load_filter=1,jitter=0,\
store_filter=0,min_latency=0,event_filter=2/ -p 4064384 -- sleep 3
# perf script -F pid,tid,addr,phys_addr
Samples for 'dummy:u' event do not have PHYS_ADDR attribute set. Cannot print 'phys_addr' field.
Masahiro Yamada [Thu, 20 Jan 2022 19:22:05 +0000 (04:22 +0900)]
certs: Fix build error when CONFIG_MODULE_SIG_KEY is empty
Since b8c96a6b466c ("certs: simplify $(srctree)/ handling and remove
config_filename macro"), when CONFIG_MODULE_SIG_KEY is empty,
signing_key.x509 fails to build:
Dmitry V. Levin [Mon, 3 Jan 2022 01:24:02 +0000 (04:24 +0300)]
usr/include/Makefile: add linux/nfc.h to the compile-test coverage
As linux/nfc.h userspace compilation was finally fixed by commits 79b69a83705e ("nfc: uapi: use kernel size_t to fix user-space builds")
and 7175f02c4e5f ("uapi: fix linux/nfc.h userspace compilation errors"),
there is no need to keep the compile-test exception for it in
usr/include/Makefile.
projects / linux.git / log