17 Oct, 2022
4 commits
-
This will provide a way for SMMU drivers to retrieve StreamIDs
associated with IORT RMR nodes and use that to set bypass settings
for those IDs.Tested-by: Steven Price
Tested-by: Laurentiu Tudor
Tested-by: Hanjun Guo
Reviewed-by: Hanjun Guo
Signed-off-by: Shameer Kolothum
Acked-by: Robin Murphy
Link: https://lore.kernel.org/r/20220615101044.1972-6-shameerali.kolothum.thodi@huawei.com
Signed-off-by: Joerg Roedel -
Parse through the IORT RMR nodes and populate the reserve region list
corresponding to a given IOMMU and device(optional). Also, go through
the ID mappings of the RMR node and retrieve all the SIDs associated
with it.Reviewed-by: Lorenzo Pieralisi
Tested-by: Steven Price
Tested-by: Laurentiu Tudor
Tested-by: Hanjun Guo
Reviewed-by: Hanjun Guo
Signed-off-by: Shameer Kolothum
Acked-by: Robin Murphy
Link: https://lore.kernel.org/r/20220615101044.1972-5-shameerali.kolothum.thodi@huawei.com
Signed-off-by: Joerg Roedel -
Currently IORT provides a helper to retrieve HW MSI reserve regions.
Change this to a generic helper to retrieve any IORT related reserve
regions. This will be useful when we add support for RMR nodes in
subsequent patches.[Lorenzo: For ACPI IORT]
Reviewed-by: Lorenzo Pieralisi
Reviewed-by: Christoph Hellwig
Tested-by: Steven Price
Tested-by: Laurentiu Tudor
Tested-by: Hanjun Guo
Reviewed-by: Hanjun Guo
Signed-off-by: Shameer Kolothum
Acked-by: Robin Murphy
Link: https://lore.kernel.org/r/20220615101044.1972-4-shameerali.kolothum.thodi@huawei.com
Signed-off-by: Joerg Roedel -
At present iort_iommu_msi_get_resv_regions() returns the number of
MSI reserved regions on success and there are no users for this.
The reserved region list will get populated anyway for platforms
that require the HW MSI region reservation. Hence, change the
function to return void instead.Reviewed-by: Christoph Hellwig
Tested-by: Steven Price
Tested-by: Laurentiu Tudor
Reviewed-by: Hanjun Guo
Signed-off-by: Shameer Kolothum
Acked-by: Robin Murphy
Link: https://lore.kernel.org/r/20220615101044.1972-3-shameerali.kolothum.thodi@huawei.com
Signed-off-by: Joerg Roedel
20 Sep, 2022
1 commit
-
commit 9946e39fe8d0a5da9eb947d8e40a7ef204ba016e upstream.
IRQ override isn't needed on modern AMD Zen systems.
There's an active low keyboard IRQ on AMD Ryzen 6000 and it will stay
this way on newer platforms. This IRQ override breaks keyboards for
almost all Ryzen 6000 laptops currently on the market.Skip this IRQ override for all AMD Zen platforms because this IRQ
override is supposed to be a workaround for buggy ACPI DSDT and we can't
have a long list of all future AMD CPUs/Laptops in the kernel code.
If a device with buggy ACPI DSDT shows up, a separated list containing
just them should be created.Link: https://bugzilla.kernel.org/show_bug.cgi?id=216118
Suggested-by: Mario Limonciello
Signed-off-by: Chuanhong Guo
Acked-by: Mario Limonciello
Tested-by: XiaoYan Li
Signed-off-by: Rafael J. Wysocki
Signed-off-by: Greg Kroah-Hartman
05 Sep, 2022
1 commit
-
commit e5b5d25444e9ee3ae439720e62769517d331fa39 upstream.
Address of a field inside a struct can't possibly be null; gcc-12 warns
about this.Signed-off-by: Adam Borowski
Signed-off-by: Rafael J. Wysocki
Cc: Sudip Mukherjee
Signed-off-by: Greg Kroah-Hartman
31 Aug, 2022
1 commit
-
commit 36527b9d882362567ceb4eea8666813280f30e6f upstream.
The freq Qos request would be removed repeatedly if the cpufreq policy
relates to more than one CPU. Then, it would cause the "called for unknown
object" warning.Remove the freq Qos request for each CPU relates to the cpufreq policy,
instead of removing repeatedly for the last CPU of it.Fixes: a1bb46c36ce3 ("ACPI: processor: Add QoS requests for all CPUs")
Reported-by: Jeremy Linton
Tested-by: Jeremy Linton
Signed-off-by: Riwen Lu
Cc: 5.4+ # 5.4+
Signed-off-by: Rafael J. Wysocki
Signed-off-by: Greg Kroah-Hartman
25 Aug, 2022
2 commits
-
[ Upstream commit 40a6cc141b4b9580de140bcb3e893445708acc5d ]
Guard ARM64-specific quirks with CONFIG_ARM64 to avoid build errors,
since mcfg_quirks will be shared by more than one architectures.Link: https://lore.kernel.org/r/20220714124216.1489304-2-chenhuacai@loongson.cn
Signed-off-by: Huacai Chen
Signed-off-by: Bjorn Helgaas
Signed-off-by: Sasha Levin -
commit 85140ef275f577f64e8a2c5789447222dfc14fc4 upstream.
The value acpi_add_nondev_subnodes() returns is bool so change the return
type of the function to match that.Fixes: 445b0eb058f5 ("ACPI / property: Add support for data-only subnodes")
Signed-off-by: Sakari Ailus
Reviewed-by: Andy Shevchenko
Signed-off-by: Rafael J. Wysocki
Signed-off-by: Greg Kroah-Hartman
17 Aug, 2022
9 commits
-
[ Upstream commit 4f4179fcf420873002035cf1941d844c9e0e7cb3 ]
There is a problem with the current revision checks in
is_cppc_supported() that they essentially prevent the CPPC support
from working if a new _CPC package format revision being a proper
superset of the v3 and only causing _CPC to return a package with more
entries (while retaining the types and meaning of the entries defined by
the v3) is introduced in the future and used by the platform firmware.In that case, as long as the number of entries in the _CPC return
package is at least CPPC_V3_NUM_ENT, it should be perfectly fine to
use the v3 support code and disregard the additional package entries
added by the new package format revision.For this reason, drop is_cppc_supported() altogether, put the revision
checks directly into acpi_cppc_processor_probe() so they are easier to
follow and rework them to take the case mentioned above into account.Fixes: 4773e77cdc9b ("ACPI / CPPC: Add support for CPPC v3")
Cc: 4.18+ # 4.18+
Signed-off-by: Rafael J. Wysocki
Signed-off-by: Sasha Levin -
[ Upstream commit 3dcb861dbc6ab101838a1548b1efddd00ca3c3ec ]
Currently acpi_viot_init() gets called after the pci
device has been scanned and pci_enable_acs() has been called.
So pci_request_acs() fails to be taken into account leading
to wrong single iommu group topologies when dealing with
multi-function root ports for instance.We cannot simply move the acpi_viot_init() earlier, similarly
as the IORT init because the VIOT parsing relies on the pci
scan. However we can detect VIOT is present earlier and in
such a case, request ACS. Introduce a new acpi_viot_early_init()
routine that allows to call pci_request_acs() before the scan.While at it, guard the call to pci_request_acs() with #ifdef
CONFIG_PCI.Fixes: 3cf485540e7b ("ACPI: Add driver for the VIOT table")
Signed-off-by: Eric Auger
Reported-by: Jin Liu
Reviewed-by: Jean-Philippe Brucker
Tested-by: Jean-Philippe Brucker
Signed-off-by: Rafael J. Wysocki
Signed-off-by: Sasha Levin -
[ Upstream commit dc4e8c07e9e2f69387579c49caca26ba239f7270 ]
From commit e147133a42cb ("ACPI / APEI: Make hest.c manage the estatus
memory pool") was merged, ghes_init() relies on acpi_hest_init() to manage
the estatus memory pool. On the other hand, ghes_init() relies on
sdei_init() to detect the SDEI version and (un)register events. The
dependencies are as follows:ghes_init() => acpi_hest_init() => acpi_bus_init() => acpi_init()
ghes_init() => sdei_init()HEST is not PCI-specific and initcall ordering is implicit and not
well-defined within a level.Based on above, remove acpi_hest_init() from acpi_pci_root_init() and
convert ghes_init() and sdei_init() from initcalls to explicit calls in the
following order:acpi_hest_init()
ghes_init()
sdei_init()Signed-off-by: Shuai Xue
Signed-off-by: Rafael J. Wysocki
Signed-off-by: Sasha Levin -
[ Upstream commit b13a3e5fd40b7d1b394c5ecbb5eb301a4c38e7b2 ]
When a platform marks a memory range as "special purpose" it is not
onlined as System RAM by default. However, it is still suitable for
error injection. Add IORES_DESC_SOFT_RESERVED to einj_error_inject() as
a permissible memory type in the sanity checking of the arguments to
_EINJ.Fixes: 262b45ae3ab4 ("x86/efi: EFI soft reservation to E820 enumeration")
Reviewed-by: Tony Luck
Reported-by: Omar Avelar
Signed-off-by: Dan Williams
Signed-off-by: Rafael J. Wysocki
Signed-off-by: Sasha Levin -
[ Upstream commit 409dfdcaffb266acfc1f33529a26b1443c9332d4 ]
Commit 6727ad9e206c ("nmi_backtrace: generate one-line reports for idle cpus")
introduced a new text section called cpuidle; with that, we have a mechanism
to add idling functions in such section and skip them from nmi_backtrace
output, since they're useless and potentially flooding for such report.Happens that inlining might cause some real idle functions to end-up
outside of such section; this is currently the case of ACPI processor_idle
driver; the functions acpi_idle_enter_* do inline acpi_idle_do_entry(),
hence they stay out of the cpuidle section.
Fix that by marking such functions to also live in the cpuidle section.Fixes: 6727ad9e206c ("nmi_backtrace: generate one-line reports for idle cpus")
Signed-off-by: Guilherme G. Piccoli
Signed-off-by: Rafael J. Wysocki
Signed-off-by: Sasha Levin -
[ Upstream commit b4f1f61ed5928b1128e60e38d0dffa16966f06dc ]
register_device_clock() misses a check for platform_device_register_simple().
Add a check to fix it.Signed-off-by: huhai
Signed-off-by: Rafael J. Wysocki
Signed-off-by: Sasha Levin -
[ Upstream commit 4b7ef7b05afcde44142225c184bf43a0cd9e2178 ]
[821d6f0359b0614792ab8e2fb93b503e25a65079] is to make machines
produced from 2012 to now not saving NVS region to accelerate S3.But, Lenovo G40-45, a platform released in 2015, still needs NVS memory
saving during S3. A quirk is introduced for this platform.Signed-off-by: Manyi Li
Signed-off-by: Rafael J. Wysocki
Signed-off-by: Sasha Levin -
[ Upstream commit f7090e0ef360d674f08a22fab90e4e209fb1f658 ]
It seems that these quirks are no longer necessary since
commit 69b957c26b32 ("ACPI: EC: Fix possible issues related to EC
initialization order"), which has fixed this in a generic manner.There are 3 commits adding DMI entries with this quirk (adding multiple
DMI entries per commit). 2/3 commits are from before the generic fix.Which leaves commit 6306f0431914 ("ACPI: EC: Make more Asus laptops
use ECDT _GPE"), which was committed way after the generic fix.
But this was just due to slow upstreaming of it. This commit stems
from Endless from 15 Aug 2017 (committed upstream 20 May 2021):
https://github.com/endlessm/linux/pull/288The current code should work fine without this:
1. The EC_FLAGS_IGNORE_DSDT_GPE flag is only checked in ec_parse_device(),
like this:if (boot_ec && boot_ec_is_ecdt && EC_FLAGS_IGNORE_DSDT_GPE) {
ec->gpe = boot_ec->gpe;
} else {
/* parse GPE */
}2. ec_parse_device() is only called from acpi_ec_add() and
acpi_ec_dsdt_probe()3. acpi_ec_dsdt_probe() starts with:
if (boot_ec)
return;so it only calls ec_parse_device() when boot_ec == NULL, meaning that
the quirk never triggers for this call. So only the call in
acpi_ec_add() matters.4. acpi_ec_add() does the following after the ec_parse_device() call:
if (boot_ec && ec->command_addr == boot_ec->command_addr &&
ec->data_addr == boot_ec->data_addr &&
!EC_FLAGS_TRUST_DSDT_GPE) {
/*
* Trust PNP0C09 namespace location rather than
* ECDT ID. But trust ECDT GPE rather than _GPE
* because of ASUS quirks, so do not change
* boot_ec->gpe to ec->gpe.
*/
boot_ec->handle = ec->handle;
acpi_handle_debug(ec->handle, "duplicated.\n");
acpi_ec_free(ec);
ec = boot_ec;
}The quirk only matters if boot_ec != NULL and EC_FLAGS_TRUST_DSDT_GPE
is never set at the same time as EC_FLAGS_IGNORE_DSDT_GPE.That means that if the addresses match we always enter this if block and
then only the ec->handle part of the data stored in ec by ec_parse_device()
is used and the rest is thrown away, after which ec is made to point
to boot_ec, at which point ec->gpe == boot_ec->gpe, so the same result
as with the quirk set, independent of the value of the quirk.Also note the comment in this block which indicates that the gpe result
from ec_parse_device() is deliberately not taken to deal with buggy
Asus laptops and all DMI quirks setting EC_FLAGS_IGNORE_DSDT_GPE are for
Asus laptops.Based on the above I believe that unless on some quirked laptops
the ECDT and DSDT EC addresses do not match we can drop the quirk.I've checked dmesg output to ensure the ECDT and DSDT EC addresses match
for quirked models using https://linux-hardware.org hw-probe reports.I've been able to confirm that the addresses match for the following
models this way: GL702VMK, X505BA, X505BP, X550VXK, X580VD.
Whereas for the following models I could find any dmesg output:
FX502VD, FX502VE, X542BA, X542BP.Note the models without dmesg all were submitted in patches with a batch
of models and other models from the same batch checkout ok.This, combined with that all the code adding the quirks was written before
the generic fix makes me believe that it is safe to remove this quirk now.Signed-off-by: Hans de Goede
Reviewed-by: Daniel Drake
Signed-off-by: Rafael J. Wysocki
Signed-off-by: Sasha Levin -
[ Upstream commit 0dd6db359e5f206cbf1dd1fd40dd211588cd2725 ]
Somehow the "ThinkPad X1 Carbon 6th" entry ended up twice in the
struct dmi_system_id acpi_ec_no_wakeup[] array. Remove one of
the entries.Signed-off-by: Hans de Goede
Signed-off-by: Rafael J. Wysocki
Signed-off-by: Sasha Levin
11 Aug, 2022
3 commits
-
commit c3481b6b75b4797657838f44028fd28226ab48e0 upstream.
The fix in commit 3f8dec116210 ("ACPI/APEI: Limit printable size of BERT
table data") does not work as intended on systems where the BIOS has a
fixed size block of memory for the BERT table, relying on s/w to quit
when it finds a record with estatus->block_status == 0. On these systems
all errors are suppressed because the check:if (region_len < ACPI_BERT_PRINT_MAX_LEN)
always fails.
New scheme skips individual CPER records that are too large, and also
limits the total number of records that will be printed to 5.Fixes: 3f8dec116210 ("ACPI/APEI: Limit printable size of BERT table data")
Cc: All applicable
Signed-off-by: Tony Luck
Signed-off-by: Rafael J. Wysocki
Signed-off-by: Greg Kroah-Hartman -
commit f0341e67b3782603737f7788e71bd3530012a4f4 upstream.
Taking a recent change in the i8042 quirklist to this one: Clevo
board_names are somewhat unique, and if not: The generic Board_-/Sys_Vendor
string "Notebook" doesn't help much anyway. So identifying the devices just
by the board_name helps keeping the list significantly shorter and might
even hit more devices requiring the fix.Signed-off-by: Werner Sembach
Fixes: c844d22fe0c0 ("ACPI: video: Force backlight native for Clevo NL5xRU and NL5xNU")
Cc: All applicable
Reviewed-by: Hans de Goede
Signed-off-by: Rafael J. Wysocki
Signed-off-by: Greg Kroah-Hartman -
commit c752089f7cf5b5800c6ace4cdd1a8351ee78a598 upstream.
The TongFang PF5PU1G, PF4NU1F, PF5NU1G, and PF5LUXG/TUXEDO BA15 Gen10,
Pulse 14/15 Gen1, and Pulse 15 Gen2 have the same problem as the Clevo
NL5xRU and NL5xNU/TUXEDO Aura 15 Gen1 and Gen2:
They have a working native and video interface. However the default
detection mechanism first registers the video interface before
unregistering it again and switching to the native interface during boot.
This results in a dangling SBIOS request for backlight change for some
reason, causing the backlight to switch to ~2% once per boot on the first
power cord connect or disconnect event. Setting the native interface
explicitly circumvents this buggy behaviour by avoiding the unregistering
process.Signed-off-by: Werner Sembach
Cc: All applicable
Reviewed-by: Hans de Goede
Signed-off-by: Rafael J. Wysocki
Signed-off-by: Greg Kroah-Hartman
22 Jul, 2022
1 commit
-
[ Upstream commit 5ad26161a371e4aa2d2553286f0cac580987a493 ]
Commit 3a0cf7ab8df3 ("ACPI: video: Change how we determine if brightness
key-presses are handled") made acpi_video_handles_brightness_key_presses()
report false when none of the ACPI Video Devices support backlight control.But it turns out that at least on a Dell Inspiron N4010 there is no ACPI
backlight control, yet brightness hotkeys are still reported through
the ACPI Video Bus; and since acpi_video_handles_brightness_key_presses()
now returns false, brightness keypresses are now reported twice.To fix this rename the has_backlight flag to may_report_brightness_keys and
also set it the first time a brightness key press event is received.Depending on the delivery of the other ACPI (WMI) event vs the ACPI Video
Bus event this means that the first brightness key press might still get
reported twice, but all further keypresses will be filtered as before.Note that this relies on other drivers reporting brightness key events
calling acpi_video_handles_brightness_key_presses() when delivering
the events (rather then once during driver probe). This is already
required and documented in include/acpi/video.h:/*
* Note: The value returned by acpi_video_handles_brightness_key_presses()
* may change over time and should not be cached.
*/Fixes: 3a0cf7ab8df3 ("ACPI: video: Change how we determine if brightness key-presses are handled")
Link: https://lore.kernel.org/regressions/CALF=6jEe5G8+r1Wo0vvz4GjNQQhdkLT5p8uCHn6ZXhg4nsOWow@mail.gmail.com/
Reported-and-tested-by: Ben Greening
Signed-off-by: Hans de Goede
Acked-by: Rafael J. Wysocki
Link: https://lore.kernel.org/r/20220713211101.85547-2-hdegoede@redhat.com
Signed-off-by: Sasha Levin
07 Jul, 2022
1 commit
-
commit 3a0cf7ab8df3878a7e2f3d29275b785cf4e7afb6 upstream.
Some systems have an ACPI video bus but not ACPI video devices with
backlight capability. On these devices brightness key-presses are
(logically) not reported through the ACPI video bus.Change how acpi_video_handles_brightness_key_presses() determines if
brightness key-presses are handled by the ACPI video driver to avoid
vendor specific drivers/platform/x86 drivers filtering out their
brightness key-presses even though they are the only ones reporting
these presses.Fixes: ed83c9171829 ("platform/x86: panasonic-laptop: Resolve hotkey double trigger bug")
Reported-and-tested-by: Stefan Seyfried
Reported-and-tested-by: Kenneth Chan
Signed-off-by: Hans de Goede
Acked-by: Rafael J. Wysocki
Reviewed-by: Andy Shevchenko
Link: https://lore.kernel.org/r/20220624112340.10130-2-hdegoede@redhat.com
Signed-off-by: Greg Kroah-Hartman
09 Jun, 2022
3 commits
-
commit 3bd561e1572ee02a50cd1a5be339abf1a5b78d56 upstream.
struct acpi_device_properties describes one source of properties present
on either struct acpi_device or struct acpi_data_node. When properties are
parsed, both are populated but when released, only those properties that
are associated with the device node are freed.Fix this by also releasing memory of the data node properties.
Fixes: 5f5e4890d57a ("ACPI / property: Allow multiple property compatible _DSD entries")
Cc: 4.20+ # 4.20+
Signed-off-by: Sakari Ailus
Reviewed-by: Andy Shevchenko
Signed-off-by: Rafael J. Wysocki
Signed-off-by: Greg Kroah-Hartman -
[ Upstream commit 6380b7b2b29da9d9c5ab2d4a265901cd93ba3696 ]
The transition_delay_us (struct cpufreq_policy) is currently defined
as:
Preferred average time interval between consecutive invocations of
the driver to set the frequency for this policy. To be set by the
scaling driver (0, which is the default, means no preference).
The transition_latency represents the amount of time necessary for a
CPU to change its frequency.A PCCT table advertises mutliple values:
- pcc_nominal: Expected latency to process a command, in microseconds
- pcc_mpar: The maximum number of periodic requests that the subspace
channel can support, reported in commands per minute. 0 indicates no
limitation.
- pcc_mrtt: The minimum amount of time that OSPM must wait after the
completion of a command before issuing the next command,
in microseconds.
cppc_get_transition_latency() allows to get the max of them.commit d4f3388afd48 ("cpufreq / CPPC: Set platform specific
transition_delay_us") allows to select transition_delay_us based on
the platform, and fallbacks to cppc_get_transition_latency()
otherwise.If _CPC objects are not using PCC channels (no PPCT table), the
transition_delay_us is set to CPUFREQ_ETERNAL, leading to really long
periods between frequency updates (~4s).If the desired_reg, where performance requests are written, is in
SystemMemory or SystemIo ACPI address space, there is no delay
in requests. So return 0 instead of CPUFREQ_ETERNAL, leading to
transition_delay_us being set to LATENCY_MULTIPLIER us (1000 us).This patch also adds two macros to check the address spaces.
Signed-off-by: Pierre Gondois
Reviewed-by: Sudeep Holla
Signed-off-by: Rafael J. Wysocki
Signed-off-by: Sasha Levin -
[ Upstream commit d52848620de00cde4a3a5df908e231b8c8868250 ]
ASUS B1400CEAE fails to resume from suspend to idle by default. This was
bisected back to commit df4f9bc4fb9c ("nvme-pci: add support for ACPI
StorageD3Enable property") but this is a red herring to the problem.Before this commit the system wasn't getting into deepest sleep state.
Presumably this commit is allowing entry into deepest sleep state as
advertised by firmware, but there are some other problems related to
the wakeup.As it is confirmed the system works properly with S3, set the default for
this system to S3.Reported-by: Jian-Hong Pan
Link: https://bugzilla.kernel.org/show_bug.cgi?id=215742
Signed-off-by: Mario Limonciello
Tested-by: Jian-Hong Pan
Signed-off-by: Rafael J. Wysocki
Signed-off-by: Sasha Levin
30 May, 2022
1 commit
-
commit 1bbc21785b7336619fb6a67f1fff5afdaf229acc upstream.
Currently the sysfs interface maps the BERT error region as "memory"
(through acpi_os_map_memory()) in order to copy the error records into
memory buffers through memory operations (eg memory_read_from_buffer()).The OS system cannot detect whether the BERT error region is part of
system RAM or it is "device memory" (eg BMC memory) and therefore it
cannot detect which memory attributes the bus to memory support (and
corresponding kernel mapping, unless firmware provides the required
information).The acpi_os_map_memory() arch backend implementation determines the
mapping attributes. On arm64, if the BERT error region is not present in
the EFI memory map, the error region is mapped as device-nGnRnE; this
triggers alignment faults since memcpy unaligned accesses are not
allowed in device-nGnRnE regions.The ACPI sysfs code cannot therefore map by default the BERT error
region with memory semantics but should use a safer default.Change the sysfs code to map the BERT error region as MMIO (through
acpi_os_map_iomem()) and use the memcpy_fromio() interface to read the
error region into the kernel buffer.Link: https://lore.kernel.org/linux-arm-kernel/31ffe8fc-f5ee-2858-26c5-0fd8bdd68702@arm.com
Link: https://lore.kernel.org/linux-acpi/CAJZ5v0g+OVbhuUUDrLUCfX_mVqY_e8ubgLTU98=jfjTeb4t+Pw@mail.gmail.com
Signed-off-by: Lorenzo Pieralisi
Tested-by: Veronika Kabatova
Tested-by: Aristeu Rozanski
Acked-by: Ard Biesheuvel
Signed-off-by: Rafael J. Wysocki
Cc: dann frazier
Signed-off-by: Greg Kroah-Hartman
09 May, 2022
2 commits
-
commit fc45e55ebc58dbf622cb89ddbf797589c7a5510b upstream.
The "safe state" index is used by acpi_idle_enter_bm() to avoid
entering a C-state that may require bus mastering to be disabled
on entry in the cases when this is not going to happen. For this
reason, it should not be set to point to C3 type of C-states, because
they may require bus mastering to be disabled on entry in principle.This was broken by commit d6b88ce2eb9d ("ACPI: processor idle: Allow
playing dead in C3 state") which inadvertently allowed the "safe
state" index to point to C3 type of C-states.This results in a machine that won't boot past the point when it first
enters C3. Restore the correct behaviour (either demote to C1/C2, or
use C3 but also set ARB_DIS=1).I hit this on a Fujitsu Siemens Lifebook S6010 (P3) machine.
Fixes: d6b88ce2eb9d ("ACPI: processor idle: Allow playing dead in C3 state")
Cc: 5.16+ # 5.16+
Signed-off-by: Ville Syrjälä
Tested-by: Woody Suwalski
[ rjw: Subject and changelog adjustments ]
Signed-off-by: Rafael J. Wysocki
Signed-off-by: Greg Kroah-Hartman -
commit 20e582e16af24b074e583f9551fad557882a3c9d upstream.
This reverts commit bfe55a1f7fd6bfede16078bf04c6250fbca11588.
This was presumably misdiagnosed as an inability to use C3 at
all when I suspect the real problem is just misconfiguration of
C3 vs. ARB_DIS.Signed-off-by: Ville Syrjälä
Cc: 5.16+ # 5.16+
Tested-by: Woody Suwalski
Signed-off-by: Rafael J. Wysocki
Signed-off-by: Greg Kroah-Hartman
20 Apr, 2022
3 commits
-
commit bfe55a1f7fd6bfede16078bf04c6250fbca11588 upstream.
Add and ACPI idle power level limit for 32-bit ThinkPad T40.
There is a regression on T40 introduced by commit d6b88ce2, starting
with kernel 5.16:commit d6b88ce2eb9d2698eb24451eb92c0a1649b17bb1
Author: Richard Gong
Date: Wed Sep 22 08:31:16 2021 -0500ACPI: processor idle: Allow playing dead in C3 state
The above patch is trying to enter C3 state during init, what is causing
a T40 system freeze. I have not found a similar issue on any other of my
32-bit machines.The fix is to add another exception to the processor_power_dmi_table[] list.
As a result the dmesg shows as expected:[2.155398] ACPI: IBM ThinkPad T40 detected - limiting to C2 max_cstate. Override with "processor.max_cstate=9"
[2.155404] ACPI: processor limited to max C-state 2The fix is trivial and affects only vintage T40 systems.
Fixes: d6b88ce2eb9d ("CPI: processor idle: Allow playing dead in C3 state")
Signed-off-by: Woody Suwalski
Reviewed-by: Hans de Goede
Cc: 5.16+ # 5.16+
[ rjw: New subject ]
Signed-off-by: Rafael J. Wysocki
Cc: "Limonciello, Mario"
Signed-off-by: Greg Kroah-Hartman -
commit d6b88ce2eb9d2698eb24451eb92c0a1649b17bb1 upstream.
When some cores are disabled on AMD platforms, the system will no longer
be able to enter suspend-to-idle s0ix.Update to allow playing dead in C3 state so that the CPUs can enter the
deepest state on AMD platforms.BugLink: https://gitlab.freedesktop.org/drm/amd/-/issues/1708
Suggested-by: Mario Limonciello
Signed-off-by: Richard Gong
[ rjw: Fixed coding style ]
Signed-off-by: Rafael J. Wysocki
Signed-off-by: Greg Kroah-Hartman -
commit eb087f305919ee8169ad65665610313e74260463 upstream.
When `osc_pc_lpi_support_confirmed` is set through `_OSC` and `_LPI` is
populated then the cpuidle driver assumes that LPI is fully functional.However currently the kernel only provides architectural support for LPI
on ARM. This leads to high power consumption on X86 platforms that
otherwise try to enable LPI.So probe whether or not LPI support is implemented before enabling LPI in
the kernel. This is done by overloading `acpi_processor_ffh_lpi_probe` to
check whether it returns `-EOPNOTSUPP`. It also means that all future
implementations of `acpi_processor_ffh_lpi_probe` will need to follow
these semantics as well.Reviewed-by: Sudeep Holla
Signed-off-by: Mario Limonciello
Signed-off-by: Rafael J. Wysocki
Signed-off-by: Greg Kroah-Hartman
08 Apr, 2022
6 commits
-
commit 40d8abf364bcab23bc715a9221a3c8623956257b upstream.
If the NumEntries field in the _CPC return package is less than 2, do
not attempt to access the "Revision" element of that package, because
it may not be present then.Fixes: 337aadff8e45 ("ACPI: Introduce CPU performance controls using CPPC")
BugLink: https://lore.kernel.org/lkml/20220322143534.GC32582@xsang-OptiPlex-9020/
Reported-by: kernel test robot
Signed-off-by: Rafael J. Wysocki
Reviewed-by: Huang Rui
Signed-off-by: Greg Kroah-Hartman -
[ Upstream commit 3f8dec116210ca649163574ed5f8df1e3b837d07 ]
Platforms with large BERT table data can trigger soft lockup errors
while attempting to print the entire BERT table data to the console at
boot:watchdog: BUG: soft lockup - CPU#160 stuck for 23s! [swapper/0:1]
Observed on Ampere Altra systems with a single BERT record of ~250KB.
The original bert driver appears to have assumed relatively small table
data. Since it is impractical to reassemble large table data from
interwoven console messages, and the table data is available in/sys/firmware/acpi/tables/data/BERT
limit the size for tables printed to the console to 1024 (for no reason
other than it seemed like a good place to kick off the discussion, would
appreciate feedback from existing users in terms of what size would
maintain their current usage model).Alternatively, we could make printing a CONFIG option, use the
bert_disable boot arg (or something similar), or use a debug log level.
However, all those solutions require extra steps or change the existing
behavior for small table data. Limiting the size preserves existing
behavior on existing platforms with small table data, and eliminates the
soft lockups for platforms with large table data, while still making it
available.Signed-off-by: Darren Hart
Signed-off-by: Rafael J. Wysocki
Signed-off-by: Sasha Levin -
[ Upstream commit 0c9992315e738e7d6e927ef36839a466b080dba6 ]
ACPICA commit b1c3656ef4950098e530be68d4b589584f06cddc
Prevent acpi_ns_walk_namespace() from crashing when called with
start_node equal to ACPI_ROOT_OBJECT if the Namespace has not been
instantiated yet and acpi_gbl_root_node is NULL.For instance, this can happen if the kernel is run with "acpi=off"
in the command line.Link: https://github.com/acpica/acpica/commit/b1c3656ef4950098e530be68d4b589584f06cddc
Link: https://lore.kernel.org/linux-acpi/CAJZ5v0hJWW_vZ3wwajE7xT38aWjY7cZyvqMJpXHzUL98-SiCVQ@mail.gmail.com/
Reported-by: Hans de Goede
Signed-off-by: Rafael J. Wysocki
Signed-off-by: Sasha Levin -
[ Upstream commit f3303ff649dbf7dcdc6a6e1a922235b12b3028f4 ]
__setup() handlers should return 1 to indicate that the boot option
has been handled. Returning 0 causes a boot option to be listed in
the Unknown kernel command line parameters and also added to init's
arg list (if no '=' sign) or environment list (if of the form 'a=b').Unknown kernel command line parameters "erst_disable
bert_disable hest_disable BOOT_IMAGE=/boot/bzImage-517rc6", will be
passed to user space.Run /sbin/init as init process
with arguments:
/sbin/init
erst_disable
bert_disable
hest_disable
with environment:
HOME=/
TERM=linux
BOOT_IMAGE=/boot/bzImage-517rc6Fixes: a3e2acc5e37b ("ACPI / APEI: Add Boot Error Record Table (BERT) support")
Fixes: a08f82d08053 ("ACPI, APEI, Error Record Serialization Table (ERST) support")
Fixes: 9dc966641677 ("ACPI, APEI, HEST table parsing")
Signed-off-by: Randy Dunlap
Reported-by: Igor Zhbanov
Link: lore.kernel.org/r/64644a2f-4a20-bab3-1e15-3b2cdd0defe3@omprussia.ru
Reviewed-by: "Huang, Ying"
Signed-off-by: Rafael J. Wysocki
Signed-off-by: Sasha Levin -
commit babc92da5928f81af951663fc436997352e02d3a upstream.
__acpi_node_get_property_reference() is documented to return -ENOENT if
the caller requests a property reference at an index that does not exist,
not -EINVAL which it actually does.Fix this by returning -ENOENT consistenly, independently of whether the
property value is a plain reference or a package.Fixes: c343bc2ce2c6 ("ACPI: properties: Align return codes of __acpi_node_get_property_reference()")
Cc: 4.14+ # 4.14+
Signed-off-by: Sakari Ailus
Signed-off-by: Rafael J. Wysocki
Signed-off-by: Greg Kroah-Hartman -
commit 2ca8e6285250c07a2e5a22ecbfd59b5a4ef73484 upstream.
Revert commit 159d8c274fd9 ("ACPI: Pass the same capabilities to the
_OSC regardless of the query flag") which caused legitimate usage
scenarios (when the platform firmware does not want the OS to control
certain platform features controlled by the system bus scope _OSC) to
break and was misguided by some misleading language in the _OSC
definition in the ACPI specification (in particular, Section 6.2.11.1.3
"Sequence of _OSC Calls" that contradicts other perts of the _OSC
definition).Link: https://lore.kernel.org/linux-acpi/CAJZ5v0iStA0JmO0H3z+VgQsVuQONVjKPpw0F5HKfiq=Gb6B5yw@mail.gmail.com
Reported-by: Mario Limonciello
Signed-off-by: Rafael J. Wysocki
Tested-by: Mario Limonciello
Acked-by: Huang Rui
Reviewed-by: Mika Westerberg
Signed-off-by: Greg Kroah-Hartman
28 Mar, 2022
2 commits
-
commit c844d22fe0c0b37dc809adbdde6ceb6462c43acf upstream.
Clevo NL5xRU and NL5xNU/TUXEDO Aura 15 Gen1 and Gen2 have both a working
native and video interface. However the default detection mechanism first
registers the video interface before unregistering it again and switching
to the native interface during boot. This results in a dangling SBIOS
request for backlight change for some reason, causing the backlight to
switch to ~2% once per boot on the first power cord connect or disconnect
event. Setting the native interface explicitly circumvents this buggy
behaviour by avoiding the unregistering process.Signed-off-by: Werner Sembach
Cc: All applicable
Signed-off-by: Rafael J. Wysocki
Signed-off-by: Greg Kroah-Hartman -
commit 7dacee0b9efc8bd061f097b1a8d4daa6591af0c6 upstream.
For some reason, the Microsoft Surface Go 3 uses the standard ACPI
interface for battery information, but does not use the standard PNP0C0A
HID. Instead it uses MSHW0146 as identifier. Add that ID to the driver
as this seems to work well.Additionally, the power state is not updated immediately after the AC
has been (un-)plugged, so add the respective quirk for that.Signed-off-by: Maximilian Luz
Cc: All applicable
Signed-off-by: Rafael J. Wysocki
Signed-off-by: Greg Kroah-Hartman
