The current code only prints PKGC-10 residency when the PKGC-10
is not reached in previous 'freeze' attempt. To debug PKGC-10 issues, we
also need to know other PKGC residency counters to better triage issues.
Ex:
1. When system is stuck in PC2, it can be caused short LTR from device.
2. When system is stuck in PC8, it can be caused by display engine.
To better triage issues, all PKGC residency are needed when issues happen.
Example log:
CPU did not enter Package C10!!! (Package C10 cnt=0x0)
Prev Package C2 cnt = 0x2191a325de, Current Package C2 cnt = 0x21aba30724
Prev Package C3 cnt = 0x0, Current Package C3 cnt = 0x0
Prev Package C6 cnt = 0x0, Current Package C6 cnt = 0x0
Prev Package C7 cnt = 0x0, Current Package C7 cnt = 0x0
Prev Package C8 cnt = 0x0, Current Package C8 cnt = 0x0
Prev Package C9 cnt = 0x0, Current Package C9 cnt = 0x0
Prev Package C10 cnt = 0x0, Current Package C10 cnt = 0x0
With this log, we can know whether it's a stuck PC2 issue, and we can
check whether the short LTR from device causes the issue.
Kai-Heng Feng [Fri, 8 Mar 2024 05:32:55 +0000 (13:32 +0800)]
platform/x86: asus-wmi: Consider device is absent when the read is ~0
AAEON PICO-TGU4 board doesn't have any LED but there are bogus LED
controls under /sys/class/leds:
$ ls /sys/class/leds
asus::kbd_backlight asus::lightbar platform::micmute
The reason is that the ~0 read from asus_wmi_get_devstate() is treated
as a valid state, in truth it means the device is absent.
So filter out ~0 read to prevent bogus LED controls being created.
Pointer item is checked fo NULL at mlxreg_hotplug_work_helper() and then
it is dereferenced to produce dev_err().
This pointer is also dereferenced before calling this function and should
never be NULL except some piece of hardware is broken as it is said in
the comment before the check. So, this check can be safely removed.
Found by Linux Verification Center (linuxtesting.org) with SVACE.
Fixes: c6acad68eb2d ("platform/mellanox: mlxreg-hotplug: Modify to use a regmap interface") Signed-off-by: Daniil Dulov <d.dulov@aladdin.ru> Reviewed-by: Vadim Pasternak <vadimp@nvidia.com> Link: https://lore.kernel.org/r/20240306153804.6509-1-d.dulov@aladdin.ru Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Shyam Sundar S K [Wed, 6 Mar 2024 11:44:14 +0000 (17:14 +0530)]
platform/x86/amd/pmf: Add support to get sps default APTS index values
During the driver probe, the default cache values for the static slider
would be obtained by evaluating the APTS method. Add support to use
these values as the thermal settings to be updated on the system based
on the changing platform-profiles.
Co-developed-by: Patil Rajesh Reddy <Patil.Reddy@amd.com> Signed-off-by: Patil Rajesh Reddy <Patil.Reddy@amd.com> Signed-off-by: Shyam Sundar S K <Shyam-sundar.S-k@amd.com> Link: https://lore.kernel.org/r/20240306114415.3267603-7-Shyam-sundar.S-k@amd.com Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Shyam Sundar S K [Wed, 6 Mar 2024 11:44:13 +0000 (17:14 +0530)]
platform/x86/amd/pmf: Add support to get APTS index numbers for static slider
APMF spec has a newer section called the APTS (AMD Performance and
Thermal State) information, where each slider/power mode is associated
with an index number.
Add support to get these indices for the Static Slider.
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Co-developed-by: Patil Rajesh Reddy <Patil.Reddy@amd.com> Signed-off-by: Patil Rajesh Reddy <Patil.Reddy@amd.com> Signed-off-by: Shyam Sundar S K <Shyam-sundar.S-k@amd.com> Link: https://lore.kernel.org/r/20240306114415.3267603-6-Shyam-sundar.S-k@amd.com Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Shyam Sundar S K [Wed, 6 Mar 2024 11:44:12 +0000 (17:14 +0530)]
platform/x86/amd/pmf: Add support to notify sbios heart beat event
Add support for newer revision of the heart beat notify events.
This event is used to notify to the OEM BIOS on driver
load/unload/suspend/resume scenarios.
If OEM BIOS does not receive the heart beat event from PMF driver, OEM
BIOS shall conclude that PMF driver is no more active and BIOS will
update to the legacy system power thermals.
Reviewed-by: Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com> Co-developed-by: Patil Rajesh Reddy <Patil.Reddy@amd.com> Signed-off-by: Patil Rajesh Reddy <Patil.Reddy@amd.com> Signed-off-by: Shyam Sundar S K <Shyam-sundar.S-k@amd.com> Link: https://lore.kernel.org/r/20240306114415.3267603-5-Shyam-sundar.S-k@amd.com Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Shyam Sundar S K [Wed, 6 Mar 2024 11:44:11 +0000 (17:14 +0530)]
platform/x86/amd/pmf: Add support to get sbios requests in PMF driver
Update the APMF function index 2 for family 1Ah, that gets the
information of SBIOS requests (like the pending requests from BIOS,
custom notifications, updation of power limits etc).
Co-developed-by: Patil Rajesh Reddy <Patil.Reddy@amd.com> Signed-off-by: Patil Rajesh Reddy <Patil.Reddy@amd.com> Signed-off-by: Shyam Sundar S K <Shyam-sundar.S-k@amd.com> Link: https://lore.kernel.org/r/20240306114415.3267603-4-Shyam-sundar.S-k@amd.com Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Shyam Sundar S K [Wed, 6 Mar 2024 11:44:10 +0000 (17:14 +0530)]
platform/x86/amd/pmf: Disable debugfs support for querying power thermals
The GET interface to receive the active power thermal information from
the PMFW has been deprecated. Hence drop the debugfs support from
version2 onwards.
Reviewed-by: Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com> Co-developed-by: Patil Rajesh Reddy <Patil.Reddy@amd.com> Signed-off-by: Patil Rajesh Reddy <Patil.Reddy@amd.com> Signed-off-by: Shyam Sundar S K <Shyam-sundar.S-k@amd.com> Link: https://lore.kernel.org/r/20240306114415.3267603-3-Shyam-sundar.S-k@amd.com Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
For family 1AH, certain PMF features have been enhanced - leading to a
newer APMF (AMD PMF) spec (BIOS and PMF driver interface) called v2.
This information would be fed into the if_version field of the
verify_interface method of the APMF call from the BIOS.
Use this information to store the version number to differentiate
between v1 or v2 and also store the information into the PMF private
data structure, as this information would be required for further code
branching to support the latest silicon.
Reviewed-by: Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com> Co-developed-by: Patil Rajesh Reddy <Patil.Reddy@amd.com> Signed-off-by: Patil Rajesh Reddy <Patil.Reddy@amd.com> Signed-off-by: Shyam Sundar S K <Shyam-sundar.S-k@amd.com> Link: https://lore.kernel.org/r/20240306114415.3267603-2-Shyam-sundar.S-k@amd.com Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Johannes Stezenbach [Tue, 5 Mar 2024 10:59:15 +0000 (11:59 +0100)]
x86/platform/atom: Check state of Punit managed devices on s2idle
For the Bay Trail or Cherry Trail SoC to enter the S0i3 power-level
at s2idle suspend requires most of the hw-blocks / devices in the SoC
to be in D3 when entering s2idle suspend.
If some devices are not in D3 then the SoC will stay in a higher
power state, consuming much more power from the battery then in S0i3.
Use the new acpi_s2idle_dev_ops and acpi_register_lps0_dev()
functionality to register a new s2idle check function which checks that
all hardware blocks in the North complex (controlled by Punit) are in
a state that allows the SoC to enter S0i3 and prints an error message
for any device in D0.
Signed-off-by: Johannes Stezenbach <js@sig21.net> Signed-off-by: Takashi Iwai <tiwai@suse.de> Acked-by: "Borislav Petkov (AMD)" <bp@alien8.de> Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
[hdegoede: Use acpi_s2idle_dev_ops] Signed-off-by: Hans de Goede <hdegoede@redhat.com> Link: https://lore.kernel.org/r/20240305105915.76242-6-hdegoede@redhat.com Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Hans de Goede [Tue, 5 Mar 2024 10:59:14 +0000 (11:59 +0100)]
platform/x86: pmc_atom: Check state of PMC clocks on s2idle
Extend the s2idle check with checking that none of the PMC clocks
is in the forced-on state. If one of the clocks is in forced on
state then S0i3 cannot be reached.
Johannes Stezenbach [Tue, 5 Mar 2024 10:59:13 +0000 (11:59 +0100)]
platform/x86: pmc_atom: Check state of PMC managed devices on s2idle
For the Bay Trail or Cherry Trail SoC to enter the S0i3 power-level
at s2idle suspend requires most of the hw-blocks / devices in the SoC
to be in D3 when entering s2idle suspend.
If some devices are not in D3 then the SoC will stay in a higher
power state, consuming much more power from the battery then in S0i3.
Use the new acpi_s2idle_dev_ops and acpi_register_lps0_dev()
functionality to register a new s2idle check function which checks that
all hardware blocks in the South complex (controlled by the PMC)
are in a state that allows the SoC to enter S0i3 and prints an error
message for any device in D0.
Some blocks are not used on lower-featured versions of the SoC and
these blocks will always report being in D0 on SoCs were they are
not used. A false-positive mask is used to identify these blocks
and for blocks in this mask the error is turned into a debug message
to avoid false-positive error messages.
Note the pmc_atom code is enabled by CONFIG_X86_INTEL_LPSS which
already depends on ACPI.
Signed-off-by: Johannes Stezenbach <js@sig21.net> Signed-off-by: Takashi Iwai <tiwai@suse.de> Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
[hdegoede: Use acpi_s2idle_dev_ops, ignore fused off blocks, PMIC I2C] Signed-off-by: Hans de Goede <hdegoede@redhat.com> Link: https://lore.kernel.org/r/20240305105915.76242-4-hdegoede@redhat.com Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Hans de Goede [Tue, 5 Mar 2024 10:59:11 +0000 (11:59 +0100)]
clk: x86: Move clk-pmc-atom register defines to include/linux/platform_data/x86/pmc_atom.h
Move the register defines for the Atom (Bay Trail, Cherry Trail) PMC
clocks to include/linux/platform_data/x86/pmc_atom.h.
This is a preparation patch to extend the S0i3 readiness checks
in drivers/platform/x86/pmc_atom.c with checking that the PMC
clocks are off on suspend entry.
Note these are added to include/linux/platform_data/x86/pmc_atom.h rather
then to include/linux/platform_data/x86/clk-pmc-atom.h because the former
already has all the other Atom PMC register defines.
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Acked-by: Stephen Boyd <sboyd@kernel.org> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Link: https://lore.kernel.org/r/20240305105915.76242-2-hdegoede@redhat.com Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Ricardo B. Marliere [Tue, 5 Mar 2024 18:55:04 +0000 (15:55 -0300)]
platform/x86: make fw_attr_class constant
Since commit 43a7206b0963 ("driver core: class: make class_register() take
a const *"), the driver core allows for struct class to be in read-only
memory, so move the fw_attr_class structure to be declared at build time
placing it into read-only memory, instead of having to be dynamically
allocated at boot time.
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Suggested-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: "Ricardo B. Marliere" <ricardo@marliere.net> Link: https://lore.kernel.org/r/20240305-class_cleanup-platform-v1-1-9085c97b9355@marliere.net Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
intel-mid.h is providing some core parts of the South Complex PM,
which are usually not used by individual drivers. In particular,
this driver doesn't use it, so simply remove the unused header.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by: Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com> Link: https://lore.kernel.org/r/20240305161539.1364717-3-andriy.shevchenko@linux.intel.com Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
intel-mid.h is providing some core parts of the South Complex PM,
which are usually not used by individual drivers. In particular,
this driver doesn't use it, so simply remove the unused header.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by: Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com> Link: https://lore.kernel.org/r/20240305161539.1364717-2-andriy.shevchenko@linux.intel.com Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Armin Wolf [Mon, 4 Mar 2024 20:50:05 +0000 (21:50 +0100)]
platform/x86/amd/pmf: Fix possible out-of-bound memory accesses
The length of the policy buffer is not validated before accessing it,
which means that multiple out-of-bounds memory accesses can occur.
This is especially bad since userspace can load policy binaries over
debugfs.
Compile-tested only.
Fixes: 7c45534afa44 ("platform/x86/amd/pmf: Add support for PMF Policy Binary") Signed-off-by: Armin Wolf <W_Armin@gmx.de> Reviewed-by: Shyam Sundar S K <Shyam-sundar.S-k@amd.com> Link: https://lore.kernel.org/r/20240304205005.10078-5-W_Armin@gmx.de Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Armin Wolf [Mon, 4 Mar 2024 20:50:04 +0000 (21:50 +0100)]
platform/x86/amd/pmf: Use struct for cookie header
The cookie header consists of a sign field and a length field.
Combine both in a single struct to make accesses simpler.
Compile-tested only.
Suggested-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Armin Wolf <W_Armin@gmx.de> Reviewed-by: Shyam Sundar S K <Shyam-sundar.S-k@amd.com> Link: https://lore.kernel.org/r/20240304205005.10078-4-W_Armin@gmx.de Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Armin Wolf [Mon, 4 Mar 2024 20:50:03 +0000 (21:50 +0100)]
platform/x86/amd/pmf: Do not use readl() for policy buffer access
The policy buffer is allocated using normal memory allocation
functions, so readl() should not be used on it.
Compile-tested only.
Fixes: 7c45534afa44 ("platform/x86/amd/pmf: Add support for PMF Policy Binary") Signed-off-by: Armin Wolf <W_Armin@gmx.de> Reviewed-by: Shyam Sundar S K <Shyam-sundar.S-k@amd.com> Link: https://lore.kernel.org/r/20240304205005.10078-3-W_Armin@gmx.de Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Armin Wolf [Mon, 4 Mar 2024 20:50:02 +0000 (21:50 +0100)]
platform/x86/amd/pmf: Fix return value of amd_pmf_start_policy_engine()
amd_pmf_start_policy_engine() returns an negative error code upon
failure, so the TA_PMF_* error codes cannot be used here.
Return -EIO instead. Also stop shadowing the return code in
amd_pmf_get_pb_data().
Compile-tested only.
Suggested-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Fixes: 7c45534afa44 ("platform/x86/amd/pmf: Add support for PMF Policy Binary") Signed-off-by: Armin Wolf <W_Armin@gmx.de> Reviewed-by: Shyam Sundar S K <Shyam-sundar.S-k@amd.com> Link: https://lore.kernel.org/r/20240304205005.10078-2-W_Armin@gmx.de Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Srinivas Pandruvada [Thu, 29 Feb 2024 00:26:59 +0000 (16:26 -0800)]
platform/x86: ISST: Allow reading core-power state on HWP disabled systems
When HWP (Hardware P-states) is disabled, dynamic SST features are
disabled. But user should still be able to read the current core-power
state, with legacy P-states. This will allow users to read current
configuration with static SST enabled from BIOS.
To address this, do not call disable_dynamic_sst_features() when the
request is for reading the state.
Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Reviewed-by: Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com> Link: https://lore.kernel.org/r/20240229002659.1416623-1-srinivas.pandruvada@linux.intel.com Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Vishnu Sankar [Wed, 28 Feb 2024 15:01:49 +0000 (00:01 +0900)]
platform/x86: thinkpad_acpi: Add more ThinkPads with non-standard reg address for fan
Add more ThinkPads with non-standard register addresses to read fan values.
ThinkPads added are L13 Yoga Gen1, X13 Yoga Gen1, L380, L390, 11e Gen5 GL,
11e Gen5 GL-R, 11e Gen5 KL-Y.
Signed-off-by: Vishnu Sankar <vishnuocv@gmail.com> Reviewed-by: Mark Pearson <mpearson-lenovo@squebb.ca> Reviewed-by: Hans de Goede <hdegoede@redhat.com> Link: https://lore.kernel.org/r/20240228150149.4799-1-vishnuocv@gmail.com Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
David E. Box [Tue, 27 Feb 2024 19:01:34 +0000 (11:01 -0800)]
platform/x86/intel/pmc/arl: Put GNA device in D3
As is the case on Meteor Lake, the Gaussian & Neural Accelerator (GNA)
device is powered by BIOS to D0 by default. If no driver is loaded, this
will cause the Package C state to be limited to PC2, leading to
significant power consumption and decrease in batter life. Put the GNA
device in D3 by default if no driver is loaded for it.
Fixes: 83f168a1a437 ("platform/x86/intel/pmc: Add Arrow Lake S support to intel_pmc_core driver") Signed-off-by: "David E. Box" <david.e.box@linux.intel.com> Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Reviewed-by: Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com> Link: https://lore.kernel.org/r/20240227190134.1592072-3-david.e.box@linux.intel.com Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
David E. Box [Tue, 27 Feb 2024 19:01:33 +0000 (11:01 -0800)]
platform/x86/intel/pmc/lnl: Remove SSRAM support
A recent PMC firmware change in Lunar Lake caused the pmc_core driver to
fail to probe. This is due to a change in the GUID for PMC telemetry coming
from the SSRAM device. Until a final release is ready this value may
change again. In the meantime, disable the SSRAM support for Lunar Lake so
the driver can load and provide some basic functionality.
Fixes: 3748dfdae2a6 ("platform/x86/intel/pmc: Add Lunar Lake M support to intel_pmc_core driver") Signed-off-by: "David E. Box" <david.e.box@linux.intel.com> Reviewed-by: Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com> Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Link: https://lore.kernel.org/r/20240227190134.1592072-2-david.e.box@linux.intel.com Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
David E. Box [Tue, 27 Feb 2024 19:01:32 +0000 (11:01 -0800)]
platform/x86/intel/vsec: Remove nuisance message
intel_vsec_walk_header() is used to configure features from devices that
don't provide a PCI VSEC or DVSEC structure. Some of these features may
be unsupported and fail to load. Ignore them silently as we do for
unsupported features described by VSEC/DVSEC.
Signed-off-by: "David E. Box" <david.e.box@linux.intel.com> Reviewed-by: Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com> Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Link: https://lore.kernel.org/r/20240227190134.1592072-1-david.e.box@linux.intel.com Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
This parameter allows predator laptop users to test and use features
(mode button, platform profile, fan speed monitoring) without
adding model names to acer_quirks and compiling kernel.
Armin Wolf [Fri, 23 Feb 2024 16:38:59 +0000 (17:38 +0100)]
platform/x86/amd/pmf: Add missing __iomem attribute to policy_base
The value of policy_base is the return value of a devm_ioremap call,
which returns a __iomem pointer instead of an regular pointer.
Add the missing __iomem attribute.
Compile-tested only.
Signed-off-by: Armin Wolf <W_Armin@gmx.de> Reviewed-by: Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com> Link: https://lore.kernel.org/r/20240223163901.13504-1-W_Armin@gmx.de Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
The whitelist-based approach for preventing older WMI drivers from
being instantiated multiple times has many drawbacks:
- uses cannot see all available WMI devices (if not whitelisted)
- whitelisting a WMI driver requires changes in the WMI driver core
- maintenance burden for driver and subsystem developers
Since the WMI driver core already takes care that older WMI drivers
are not being instantiated multiple times, remove the now redundant
whitelist.
Armin Wolf [Mon, 26 Feb 2024 19:35:56 +0000 (20:35 +0100)]
platform/x86: wmi: Do not instantiate older WMI drivers multiple times
Many older WMI drivers cannot be instantiated multiple times for
two reasons:
- they are using the legacy GUID-based WMI API
- they are singletons (with global state)
Prevent such WMI drivers from binding to WMI devices with a duplicated
GUID, as this would mean that the WMI driver will be instantiated at
least two times (one for the original GUID and one for the duplicated
GUID).
WMI drivers which can be instantiated multiple times can signal this
by setting a flag inside struct wmi_driver.
Armin Wolf [Mon, 26 Feb 2024 19:35:55 +0000 (20:35 +0100)]
platform/x86: wmi: Ignore duplicated GUIDs in legacy matches
When matching a WMI device to a GUID used by the legacy GUID-based
API, devices with a duplicated GUID should be ignored.
Add an additional WMI device flag signaling that the GUID used by
the WMI device is also used by another WMI device. Ignore such
devices inside the match functions used by the legacy GUID-based API.
Gergo Koteles [Sun, 10 Mar 2024 11:31:42 +0000 (12:31 +0100)]
platform/x86: ideapad-laptop: map Fn + R key to KEY_REFRESH_RATE_TOGGLE
Newer Lenovo Yogas and Legions with 60Hz/90Hz displays send a wmi event
when Fn + R is pressed. This is intended for use to switch between the
two refresh rates.
The Fn + R key was incorrectly assigned to KEY_DISPLAYTOGGLE because it
is used to toggle the display on and off.
Map Fn + R key to the KEY_REFRESH_RATE_TOGGLE event code.
Gergo Koteles [Sun, 10 Mar 2024 11:31:41 +0000 (12:31 +0100)]
Input: allocate keycode for Display refresh rate toggle
Newer Lenovo Yogas and Legions with 60Hz/90Hz displays send a wmi event
when Fn + R is pressed. This is intended for use to switch between the
two refresh rates.
Allocate a new KEY_REFRESH_RATE_TOGGLE keycode for it.
Harshit Mogalapalli [Mon, 26 Feb 2024 14:40:10 +0000 (06:40 -0800)]
platform/x86/amd/pmf: Fix missing error code in amd_pmf_init_smart_pc()
On the error path, assign -ENOMEM to ret when memory allocation of
"dev->prev_data" fails.
Fixes: e70961505808 ("platform/x86/amd/pmf: Fixup error handling for amd_pmf_init_smart_pc()") Signed-off-by: Harshit Mogalapalli <harshit.m.mogalapalli@oracle.com> Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Reviewed-by: Mario Limonciello <mario.limonciello@amd.com> Link: https://lore.kernel.org/r/20240226144011.2100804-1-harshit.m.mogalapalli@oracle.com Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Hans de Goede [Mon, 4 Mar 2024 13:43:55 +0000 (14:43 +0100)]
platform/x86: p2sb: On Goldmont only cache P2SB and SPI devfn BAR
On Goldmont p2sb_bar() only ever gets called for 2 devices, the actual P2SB
devfn 13,0 and the SPI controller which is part of the P2SB, devfn 13,2.
But the current p2sb code tries to cache BAR0 info for all of
devfn 13,0 to 13,7 . This involves calling pci_scan_single_device()
for device 13 functions 0-7 and the hw does not seem to like
pci_scan_single_device() getting called for some of the other hidden
devices. E.g. on an ASUS VivoBook D540NV-GQ065T this leads to continuous
ACPI errors leading to high CPU usage.
Fix this by only caching BAR0 info and thus only calling
pci_scan_single_device() for the P2SB and the SPI controller.
Fixes: 5913320eb0b3 ("platform/x86: p2sb: Allow p2sb_bar() calls during PCI device probe") Reported-by: Danil Rybakov <danilrybakov249@gmail.com> Closes: https://bugzilla.kernel.org/show_bug.cgi?id=218531 Tested-by: Danil Rybakov <danilrybakov249@gmail.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Link: https://lore.kernel.org/r/20240304134356.305375-2-hdegoede@redhat.com
Currently, the driver has two behaviors to deal with new & unsupported
performance blocks reported by the firmware:
1. For register and unknown block types, the driver will fail to load
with the following error message:
[ 4510.956369] mlxbf-pmc: probe of MLNXBFD2:00 failed with error -22
2. For counter and crspace blocks, the driver will load and sysfs files
will be created but getting the contents of event_list or trying to
setup the counter will fail
Instead, let's ignore and log unsupported blocks. This means the driver
will always load and unsupported blocks will never show up in sysfs.
Luiz Capitulino [Thu, 22 Feb 2024 20:57:29 +0000 (15:57 -0500)]
platform/mellanox: mlxbf-pmc: mlxbf_pmc_event_list(): make size ptr optional
The mlxbf_pmc_event_list() function returns a pointer to an array of
supported events and the array size. The array size is returned via
a pointer passed as an argument, which is mandatory.
However, we want to be able to use mlxbf_pmc_event_list() just to check
if a block name is implemented/supported. For this usage passing the size
argument is not necessary so let's make it optional.
Armin Wolf [Fri, 23 Feb 2024 16:29:05 +0000 (17:29 +0100)]
platform/x86: dell-privacy: Remove usage of wmi_has_guid()
The WMI driver core already takes care that the WMI driver is
only bound to WMI devices with a matching GUID.
Remove the unnecessary call to wmi_has_guid(), which will always
be true when the driver probes.
Tested on a Dell Inspiron 3505.
Signed-off-by: Armin Wolf <W_Armin@gmx.de> Reviewed-by: Hans de Goede <hdegoede@redhat.com> Link: https://lore.kernel.org/r/20240223162905.12416-1-W_Armin@gmx.de Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Armin Wolf [Mon, 19 Feb 2024 11:59:17 +0000 (12:59 +0100)]
platform/x86: wmi: Always evaluate _WED when receiving an event
The ACPI WMI specification states:
"The _WED control method is evaluated by the mapper in
response to receiving a notification from a control
method."
This means that _WED should be evaluated unconditionally even
if no WMI event consumers are present.
Some firmware implementations actually depend on this behavior
by storing the event data inside a queue which will fill up if
the WMI core stops retrieving event data items due to no
consumers being present
Fix this by always evaluating _WED even if no WMI event consumers
are present.
Armin Wolf [Mon, 19 Feb 2024 11:59:16 +0000 (12:59 +0100)]
platform/x86: wmi: Check if event data is not NULL
WMI event drivers which do not have no_notify_data set expect
that each WMI event contains valid data. Evaluating _WED however
might return no data, which can cause issues with such drivers.
Fix this by validating that evaluating _WED did return data.
Armin Wolf [Mon, 19 Feb 2024 11:59:15 +0000 (12:59 +0100)]
platform/x86: wmi: Prevent incompatible event driver from probing
If a WMI event driver has no_notify_data set, then it indicates
support for WMI events which provide no notify data, otherwise
the notify() callback expects a valid ACPI object as notify data.
However if a WMI event driver which requires notify data is bound
to a WMI event device which cannot retrieve such data due to the
_WED ACPI method being absent, then the driver will be dysfunctional
since all WMI events will be dropped due to the missing notify data.
Fix this by not allowing such WMI event drivers to bind to WMI event
devices which do not support retrieving of notify data. Also reword
the description of no_notify_data a bit.
Szilard Fabian [Thu, 15 Feb 2024 20:31:43 +0000 (20:31 +0000)]
platform/x86/fujitsu-laptop: Add battery charge control support
This patch adds battery charge control support on Fujitsu notebooks
via the S006 method of the FUJ02E3 ACPI device. With this method it's
possible to set charge_control_end_threshold between 50 and 100%.
Tested on Lifebook E5411 and Lifebook U728. Sadly I can't test this
patch on a dual battery one, but I didn't find any clue about
independent battery charge control on dual battery Fujitsu notebooks
either. And by that I mean checking the DSDT table of various Lifebook
notebooks and reverse engineering FUJ02E3.dll.
Signed-off-by: Szilard Fabian <szfabian@bluemarch.art> Acked-by: Jonathan Woithe <jwoithe@just42.net> Link: https://lore.kernel.org/r/20240215203012.228758-2-szfabian@bluemarch.art
[ij: coding style cleanups.] Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Mario Limonciello [Sat, 17 Feb 2024 02:23:11 +0000 (20:23 -0600)]
platform/x86: thinkpad_acpi: Only update profile if successfully converted
Randomly a Lenovo Z13 will trigger a kernel warning traceback from this
condition:
```
if (WARN_ON((profile < 0) || (profile >= ARRAY_SIZE(profile_names))))
```
This happens because thinkpad-acpi always assumes that
convert_dytc_to_profile() successfully updated the profile. On the
contrary a condition can occur that when dytc_profile_refresh() is called
the profile doesn't get updated as there is a -EOPNOTSUPP branch.
Catch this situation and avoid updating the profile. Also log this into
dynamic debugging in case any other modes should be added in the future.
Fixes: c3bfcd4c6762 ("platform/x86: thinkpad_acpi: Add platform profile support") Signed-off-by: Mario Limonciello <mario.limonciello@amd.com> Link: https://lore.kernel.org/r/20240217022311.113879-1-mario.limonciello@amd.com Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Hans de Goede [Fri, 16 Feb 2024 20:17:20 +0000 (21:17 +0100)]
platform/x86: x86-android-tablets: Fix serdev instantiation no longer working
After commit b286f4e87e32 ("serial: core: Move tty and serdev to be
children of serial core port device") x86_instantiate_serdev() no longer
works due to the serdev-controller-device moving in the device hierarchy
from (e.g.) /sys/devices/pci0000:00/8086228A:00/serial0 to
/sys/devices/pci0000:00/8086228A:00/8086228A:00:0/8086228A:00:0.0/serial0
Use the new get_serdev_controller() helper function to fix this.
Hans de Goede [Fri, 16 Feb 2024 20:17:19 +0000 (21:17 +0100)]
platform/x86: Add new get_serdev_controller() helper
In some cases UART attached devices which require an in kernel driver,
e.g. UART attached Bluetooth HCIs are described in the ACPI tables
by an ACPI device with a broken or missing UartSerialBusV2() resource.
This causes the kernel to create a /dev/ttyS# char-device for the UART
instead of creating an in kernel serdev-controller + serdev-device pair
for the in kernel driver.
The quirk handling in acpi_quirk_skip_serdev_enumeration() makes the kernel
create a serdev-controller device for these UARTs instead of a /dev/ttyS#.
Instantiating the actual serdev-device to bind to is up to pdx86 code,
so far this was handled by the x86-android-tablets code. But since
commit b286f4e87e32 ("serial: core: Move tty and serdev to be children of
serial core port device") the serdev-controller device has moved in the
device hierarchy from (e.g.) /sys/devices/pci0000:00/8086228A:00/serial0 to
/sys/devices/pci0000:00/8086228A:00/8086228A:00:0/8086228A:00:0.0/serial0 .
This makes this a bit trickier to do and another driver is in the works
which will also need this functionality.
Add a new helper to get the serdev-controller device, so that the new
code for this can be shared.
Hans de Goede [Fri, 16 Feb 2024 20:17:18 +0000 (21:17 +0100)]
platform/x86: x86-android-tablets: Fix keyboard touchscreen on Lenovo Yogabook1 X90
After commit 4014ae236b1d ("platform/x86: x86-android-tablets: Stop using
gpiolib private APIs") the touchscreen in the keyboard half of
the Lenovo Yogabook1 X90 stopped working with the following error:
Goodix-TS i2c-goodix_ts: error -EBUSY: Failed to get irq GPIO
The problem is that when getting the IRQ for instantiated i2c_client-s
from a GPIO (rather then using an IRQ directly from the IOAPIC),
x86_acpi_irq_helper_get() now properly requests the GPIO, which disallows
other drivers from requesting it. Normally this is a good thing, but
the goodix touchscreen also uses the IRQ as an output during reset
to select which of its 2 possible I2C addresses should be used.
Add a new free_gpio flag to struct x86_acpi_irq_data to deal with this
and release the GPIO after getting the IRQ in this special case.
Vishnu Sankar [Thu, 15 Feb 2024 13:41:02 +0000 (22:41 +0900)]
platform/x86: thinkpad_acpi: Fix to correct wrong temp reporting on some ThinkPads
Added non-standard thermal register's support for some ThinkPads.
Some of the Thinkpads use a non-standard ECFW which has different
thermal register addresses. This is a fix to correct the wrong temperature
reporting on those systems.
Tested on Lenovo ThinkPad L13 Yoga Gen2.
Suggested-by: Mark Pearson <mpearson-lenovo@squebb.ca> Signed-off-by: Vishnu Sankar <vishnuocv@gmail.com> Link: https://lore.kernel.org/r/20240215134102.25118-2-vishnuocv@gmail.com Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Add a thermal_read_mode_check helper to make the code
simpler during init. This helps particularly when the new
TPACPI_THERMAL_TPEC_12 mode is added in the next patch.
Suggested-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Vishnu Sankar <vishnuocv@gmail.com> Link: https://lore.kernel.org/r/20240215134102.25118-1-vishnuocv@gmail.com
[ij: Reflowed the comment to 80 cols, multiline if braces, added __init.] Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Mario Limonciello [Sat, 17 Feb 2024 01:56:42 +0000 (19:56 -0600)]
platform/x86/amd/pmf: Fix a potential race with policy binary sideload
The debugfs `update_policy` file is created before
amd_pmf_start_policy_engine() has completed, and thus there could be
a possible (albeit unlikely) race between sideloading a policy and the
BIOS policy getting setup.
Move the debugfs file creation after all BIOS policy is setup.
Fixes: 10817f28e533 ("platform/x86/amd/pmf: Add capability to sideload of policy binary") Reported-by: Hans de Goede <hdegoede@redhat.com> Closes: https://lore.kernel.org/platform-driver-x86/15df7d02-b0aa-457a-954a-9d280a592843@redhat.com/T/#m2c445f135e5ef9b53184be7fc9df84e15f89d4d9 Signed-off-by: Mario Limonciello <mario.limonciello@amd.com> Link: https://lore.kernel.org/r/20240217015642.113806-1-mario.limonciello@amd.com Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Mario Limonciello [Sat, 17 Feb 2024 01:41:07 +0000 (19:41 -0600)]
platform/x86/amd/pmf: Fixup error handling for amd_pmf_init_smart_pc()
amd_pmf_init_smart_pc() calls out to amd_pmf_get_bios_buffer() but
the error handling flow doesn't clean everything up allocated
memory.
As amd_pmf_get_bios_buffer() is only called by amd_pmf_init_smart_pc(),
fold it into the function and add labels to clean up any step that
can fail along the way. Explicitly set everything allocated to NULL as
there are other features that may access some of the same variables.
Fixes: 7c45534afa44 ("platform/x86/amd/pmf: Add support for PMF Policy Binary") Signed-off-by: Mario Limonciello <mario.limonciello@amd.com> Link: https://lore.kernel.org/r/20240217014107.113749-3-mario.limonciello@amd.com Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Mario Limonciello [Sat, 17 Feb 2024 00:52:16 +0000 (18:52 -0600)]
platform/x86/amd/pmf: Fix a suspend hang on Framework 13
The buffer is cleared in the suspend handler but used in
the delayed work for amd_pmf_get_metrics().
Stop clearing it to fix the hang.
Reported-by: Trolli Schmittlauch <t.schmittlauch@orlives.de> Closes: https://lore.kernel.org/regressions/ed2226ff-257b-4cfd-afd6-bf3be9785474@localhost/ Closes: https://community.frame.work/t/kernel-6-8-rc-system-freezes-after-resuming-from-suspend-reproducers-wanted/45381 Fixes: 2b3a7f06caaf ("platform/x86/amd/pmf: Change return type of amd_pmf_set_dram_addr()") Signed-off-by: Mario Limonciello <mario.limonciello@amd.com> Link: https://lore.kernel.org/r/20240217005216.113408-1-mario.limonciello@amd.com Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Shyam Sundar S K [Fri, 16 Feb 2024 06:41:12 +0000 (12:11 +0530)]
platform/x86/amd/pmf: Fix TEE enact command failure after suspend and resume
TEE enact command failures are seen after each suspend/resume cycle;
fix this by cancelling the policy builder workqueue before going into
suspend and reschedule the workqueue after resume.
Fixes: ae82cef7d9c5 ("platform/x86/amd/pmf: Add support for PMF-TA interaction") Co-developed-by: Patil Rajesh Reddy <Patil.Reddy@amd.com> Signed-off-by: Patil Rajesh Reddy <Patil.Reddy@amd.com> Signed-off-by: Shyam Sundar S K <Shyam-sundar.S-k@amd.com> Reviewed-by: Mario Limonciello <mario.limonciello@amd.com> Link: https://lore.kernel.org/r/20240216064112.962582-2-Shyam-sundar.S-k@amd.com Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Shyam Sundar S K [Fri, 16 Feb 2024 06:41:11 +0000 (12:11 +0530)]
platform/x86/amd/pmf: Remove smart_pc_status enum
Improve code readability by removing smart_pc_status enum, as the same
can be done with a simple true/false check; Update the code checks
accordingly.
Also add a missing return on amd_pmf_init_smart_pc() success,
to skip trying to setup the auto / slider modes which should
not be used in this case.
Signed-off-by: Shyam Sundar S K <Shyam-sundar.S-k@amd.com> Reviewed-by: Mario Limonciello <mario.limonciello@amd.com> Link: https://lore.kernel.org/r/20240216064112.962582-1-Shyam-sundar.S-k@amd.com Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Hans de Goede [Mon, 12 Feb 2024 12:06:08 +0000 (13:06 +0100)]
platform/x86: touchscreen_dmi: Consolidate Goodix upside-down touchscreen data
Now that prefix matches for ACPI names are supported, the ts_dmi_data
structs for "GDIX1001:00" and "GDIX1001:01" can be consolidated into
a single match matching on "GDIX1001".
For consistency also change gdix1002_00_upside_down_data to match.
Hans de Goede [Mon, 12 Feb 2024 12:06:07 +0000 (13:06 +0100)]
platform/x86: touchscreen_dmi: Allow partial (prefix) matches for ACPI names
On some devices the ACPI name of the touchscreen is e.g. either
MSSL1680:00 or MSSL1680:01 depending on the BIOS version.
This happens for example on the "Chuwi Hi8 Air" tablet where the initial
commit's ts_data uses "MSSL1680:00" but the tablets from the github issue
and linux-hardware.org probe linked below both use "MSSL1680:01".
Replace the strcmp() match on ts_data->acpi_name with a strstarts()
check to allow using a partial match on just the ACPI HID of "MSSL1680"
and change the ts_data->acpi_name for the "Chuwi Hi8 Air" accordingly
to fix the touchscreen not working on models where it is "MSSL1680:01".
Note this drops the length check for I2C_NAME_SIZE. This never was
necessary since the ACPI names used are never more then 11 chars and
I2C_NAME_SIZE is 20 so the replaced strncmp() would always stop long
before reaching I2C_NAME_SIZE.
Mark Pearson [Fri, 9 Feb 2024 15:23:47 +0000 (10:23 -0500)]
platform/x86: think-lmi: Fix password opcode ordering for workstations
The Lenovo workstations require the password opcode to be run before
the attribute value is changed (if Admin password is enabled).
Tested on some Thinkpads to confirm they are OK with this order too.
Signed-off-by: Mark Pearson <mpearson-lenovo@squebb.ca> Fixes: 640a5fa50a42 ("platform/x86: think-lmi: Opcode support") Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Link: https://lore.kernel.org/r/20240209152359.528919-1-mpearson-lenovo@squebb.ca Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Armin Wolf [Mon, 12 Feb 2024 18:50:16 +0000 (19:50 +0100)]
platform/x86: wmi: Make input buffer mandatory when evaluating methods
The ACPI-WMI specification declares in the section "ACPI Control Method
Naming Conventions and Functionality for Windows 2000 Instrumentation"
that a WMxx control method takes 3 arguments: instance, method id and
argument buffer. This is also the case even when the underlying WMI
method does not have any input arguments.
So if a WMI driver evaluates a WMI method without passing an input
buffer, ACPICA will log a warning complaining that the third argument
is missing.
Prevent this by checking that a input buffer was passed, and return
an error if this was not the case.
Tested on a Asus PRIME B650-Plus.
Reviewed-by: Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com> Signed-off-by: Armin Wolf <W_Armin@gmx.de> Link: https://lore.kernel.org/r/20240212185016.5494-1-W_Armin@gmx.de Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Ilpo Järvinen [Thu, 8 Feb 2024 11:49:31 +0000 (13:49 +0200)]
Merge tag 'platform-drivers-x86-v6.8-2' into pdx/for-next
Merge tag 'platform-drivers-x86-v6.8-2' fixes into pdf86/for-next
because of WMI fixes. The WMI changes done in for-next already created
a minor conflict with the fixes and WMI is actively being improved
currently so besides resolving the current conflict, this is also to
avoid further conflicts.
Armin Wolf [Tue, 6 Feb 2024 22:04:45 +0000 (23:04 +0100)]
platform/x86: wmi: Use FW_BUG when warning about missing control methods
A missing WQxx control method is a firmware bug and should be
marked as such using FW_BUG so that users know that the issue
is not a kernel issue.
Since get_subobj_info() might fail even if the control method
is present, we need to print the warning only if acpi_get_handle()
fails.
Armin Wolf [Tue, 6 Feb 2024 22:04:44 +0000 (23:04 +0100)]
platform/x86: wmi: Check if WMxx control method exists
Some devices like the MSI GF63-12VF contain WMI method blocks
without providing the necessary WMxx ACPI control methods.
Avoid creating WMI devices for such WMI method blocks since
the resulting WMI device is going to be unusable.
Ricardo B. Marliere [Sun, 4 Feb 2024 14:40:17 +0000 (11:40 -0300)]
platform: x86: ibm_rtl: make rtl_subsys const
Now that the driver core can properly handle constant struct bus_type,
move the rtl_subsys variable to be a constant structure as well,
placing it into read-only memory which can not be modified at runtime.
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Suggested-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: "Ricardo B. Marliere" <ricardo@marliere.net> Link: https://lore.kernel.org/r/20240204-bus_cleanup-platform-drivers-x86-v1-2-1f0839b385c6@marliere.net Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Ricardo B. Marliere [Sun, 4 Feb 2024 14:40:16 +0000 (11:40 -0300)]
platform: x86: wmi: make wmi_bus_type const
Now that the driver core can properly handle constant struct bus_type,
move the wmi_bus_type variable to be a constant structure as well,
placing it into read-only memory which can not be modified at runtime.
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Suggested-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: "Ricardo B. Marliere" <ricardo@marliere.net> Reviewed-by: Armin Wolf <W_Armin@gmx.de> Link: https://lore.kernel.org/r/20240204-bus_cleanup-platform-drivers-x86-v1-1-1f0839b385c6@marliere.net Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Alexis Belmonte [Thu, 1 Feb 2024 13:29:33 +0000 (14:29 +0100)]
platform/x86: hp-wmi: Add thermal profile support for 8BAD boards
Add 8BAD to the list of boards which have thermal profile selection
available. This allows the CPU to draw more power than the default TDP
barrier defined by the 'balanced' thermal profile (around 50W), hence
allowing it to perform better without being throttled by the embedded
controller (around 130W).
We first need to set the HP_OMEN_EC_THERMAL_PROFILE_TIMER_OFFSET to zero.
This prevents the timer countdown from reaching zero, making the embedded
controller "force-switch" the system's thermal profile back to 'balanced'
automatically.
We also need to put a number of specific flags in
HP_OMEN_EC_THERMAL_PROFILE_FLAGS_OFFSET when we're switching to another
thermal profile:
- for 'performance', we need to set both HP_OMEN_EC_FLAGS_TURBO and
HP_OMEN_EC_FLAGS_NOTIMER;
- for 'balanced' and 'powersave', we clear out the register to notify
the system that we want to lower the TDP barrier as soon as possible.
The third flag defined in the hp_thermal_profile_omen_flags enum,
HP_OMEN_EC_FLAGS_JUSTSET, is present for completeness.
To prevent potential behaviour breakage with other Omen models, a
separate omen_timed_thermal_profile_boards array has been added to list
which boards expose this behaviour.
Performance benchmarking was done with the help of silver.urih.com and
Google Chrome 120.0.6099.129, on Gnome 45.2, with the 'performance'
thermal profile set:
| | Performance | Stress | TDP |
|------------------|-------------|------------|-------|
| with my patch | P84549 | S0.1891 | 131W |
| without my patch | P44084 | S0.1359 | 47W |
The TDP measurements were done with the help of the s-tui utility,
during the load.
There is still work to be done:
- tune the CPU and GPU fans to better cool down and enhance
performance at the right time; right now, it seems that the fans are
not properly reacting to thermal/performance events, which in turn
either causes thermal throttling OR makes the fans spin way too long,
even though the temperatures have lowered down
- expose the CPU and GPU fan curves to user-land so that they can be
controlled just like what the Omen Gaming Hub utility proposes to
its users;
Signed-off-by: Alexis Belmonte <alexbelm48@gmail.com> Link: https://lore.kernel.org/r/ZbucvX2rRdqRgtcu@alexis-pc Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Armin Wolf [Tue, 30 Jan 2024 22:19:42 +0000 (23:19 +0100)]
platform/x86: wmi: Stop using ACPI device class
When an ACPI netlink event is received by acpid, the ACPI device
class is passed as its first argument. But since the class string
is not initialized during probe, an empty string is being passed:
Ashok Raj [Thu, 25 Jan 2024 08:22:54 +0000 (00:22 -0800)]
platform/x86/intel/ifs: Add an entry rendezvous for SAF
The activation for Scan at Field (SAF) includes a parameter to make
microcode wait for both threads to join. It's preferable to perform an
entry rendezvous before the activation to ensure that they start the
`wrmsr` close enough to each other. In some cases it has been observed
that one of the threads might be just a bit late to arrive. An entry
rendezvous reduces the likelihood of these cases occurring.
Add an entry rendezvous to ensure the activation on both threads happen
close enough to each other.
Signed-off-by: Ashok Raj <ashok.raj@intel.com> Reviewed-by: Tony Luck <tony.luck@intel.com> Link: https://lore.kernel.org/r/20240125082254.424859-6-ashok.raj@intel.com Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Ashok Raj [Thu, 25 Jan 2024 08:22:53 +0000 (00:22 -0800)]
platform/x86/intel/ifs: Replace the exit rendezvous with an entry rendezvous for ARRAY_BIST
ARRAY_BIST requires the test to be invoked only from one of the HT
siblings of a core. If the other sibling was in mwait(), that didn't
permit the test to complete and resulted in several retries before the
test could finish.
The exit rendezvous was introduced to keep the HT sibling busy until
the primary CPU completed the test to avoid those retries. What is
actually needed is to ensure that both the threads rendezvous *before*
the wrmsr to trigger the test to give good chance to complete the test.
The `stop_machine()` function returns only after all the CPUs complete
running the function, and provides an exit rendezvous implicitly.
In kernel/stop_machine.c::multi_cpu_stop(), every CPU in the mask
needs to complete reaching MULTI_STOP_RUN. When all CPUs complete, the
state machine moves to next state, i.e MULTI_STOP_EXIT. Thus the
underlying API stop_core_cpuslocked() already provides an exit
rendezvous.
Add the rendezvous earlier in order to ensure the wrmsr is triggered
after all CPUs reach the do_array_test(). Remove the exit rendezvous
since stop_core_cpuslocked() already guarantees that.
Signed-off-by: Ashok Raj <ashok.raj@intel.com> Reviewed-by: Tony Luck <tony.luck@intel.com> Link: https://lore.kernel.org/r/20240125082254.424859-5-ashok.raj@intel.com Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Suma Hegde [Sat, 6 Jan 2024 02:25:30 +0000 (02:25 +0000)]
platform/x86/amd/hsmp: Check num_sockets against MAX_AMD_SOCKETS
AMD supports connecting up to 8 AMD EPYCs in a system.
Hence, verify the num_sockets returned from amd_nb_num().
Also remove the WARN_ON() since the num_sockets is already verified.
Signed-off-by: Suma Hegde <suma.hegde@amd.com> Reviewed-by: Naveen Krishna Chatradhi <nchatrad@amd.com> Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Link: https://lore.kernel.org/r/20240106022532.1746932-9-suma.hegde@amd.com Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Suma Hegde [Sat, 6 Jan 2024 02:25:29 +0000 (02:25 +0000)]
platform/x86/amd/hsmp: Non-ACPI support for AMD F1A_M00~0Fh
AMD EPYC family 0x1A and Model 0x0-0xF are having different
mailbox message ID offset compared to previous
platforms. In case of ACPI based BIOS, this information will be read
from ACPI table, for non-ACPI BIOS, this needs to be #defined.
Signed-off-by: Suma Hegde <suma.hegde@amd.com> Signed-off-by: Naveen Krishna Chatradhi <nchatrad@amd.com> Reviewed-by: Hans de Goede <hdegoede@redhat.com> Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Link: https://lore.kernel.org/r/20240106022532.1746932-8-suma.hegde@amd.com Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Suma Hegde [Sat, 6 Jan 2024 02:25:28 +0000 (02:25 +0000)]
platform/x86/amd/hsmp: Add support for ACPI based probing
ACPI table provides mailbox base address and register offset
information. The base address is provided as part of CRS method
and mailbox offsets are provided through DSD table.
Sockets are differentiated by UIDs.
Signed-off-by: Suma Hegde <suma.hegde@amd.com> Signed-off-by: Naveen Krishna Chatradhi <nchatrad@amd.com> Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Link: https://lore.kernel.org/r/20240106022532.1746932-7-suma.hegde@amd.com
[ij: Removed extra parenthesis.] Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Suma Hegde [Sat, 6 Jan 2024 02:25:26 +0000 (02:25 +0000)]
platform/x86/amd/hsmp: Move dev from platdev to hsmp_socket
On an ACPI enabled platforms the probe is called for each socket
and the struct dev is different for each socket. This change
will help in handling both ACPI and non-ACPI platforms.
Also change pr_err() to dev_err() API.
Signed-off-by: Suma Hegde <suma.hegde@amd.com> Signed-off-by: Naveen Krishna Chatradhi <nchatrad@amd.com> Reviewed-by: Hans de Goede <hdegoede@redhat.com> Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Link: https://lore.kernel.org/r/20240106022532.1746932-5-suma.hegde@amd.com Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Cong Liu [Wed, 24 Jan 2024 01:29:38 +0000 (09:29 +0800)]
platform/x86/amd/pmf: Fix memory leak in amd_pmf_get_pb_data()
amd_pmf_get_pb_data() will allocate memory for the policy buffer,
but does not free it if copy_from_user() fails. This leads to a memory
leak.
Fixes: 10817f28e533 ("platform/x86/amd/pmf: Add capability to sideload of policy binary") Reviewed-by: Shyam Sundar S K <Shyam-sundar.S-k@amd.com> Signed-off-by: Cong Liu <liucong2@kylinos.cn> Link: https://lore.kernel.org/r/20240124012939.6550-1-liucong2@kylinos.cn Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
projects / linux.git / log