MASK_VAL() was added as a way to handle bit_offset and bit_width for
registers located in system memory address space. However, while suited
for reading, it does not work for writing and result in corrupted
registers when writing values with bit_offset > 0. Moreover, when a
register is collocated with another one at the same address but with a
different mask, the current code results in the other registers being
overwritten with 0s. The write procedure for SYSTEM_MEMORY registers
should actually read the value, mask it, update it and write it with the
updated value. Moreover, since registers can be located in the same
word, we must take care of locking the access before doing it. We should
potentially use a global lock since we don't know in if register
addresses aren't shared with another _CPC package but better not
encourage vendors to do so. Assume that registers can use the same word
inside a _CPC package and thus, use a per _CPC package lock.
Fixes: 2f4a4d63a1 ("ACPI: CPPC: Use access_width over bit_width for system memory accesses")
Signed-off-by: Clément Léger <cleger@rivosinc.com>
Link: https://patch.msgid.link/20240826101648.95654-1-cleger@rivosinc.com
[ rjw: Dropped redundant semicolon ]
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
ACPICA commit 6031b34b5dbabfaaebe80e57e8e415790b51d285
Only include the functions acpi_rs_dump_resource_list
and acpi_rs_dump_irq_list() if ACPI_DEBUGGER is defined, as
specified in the header.
This avoids the compiler warning by adding the ifdef for ACPI_DEBUGGER.
Link: https://github.com/acpica/acpica/commit/6031b34b
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
ACPICA commit f2cb44f6deb6325a6b348b225fc82f565a870899
Add "0x" prefix for explicitly converted integers
and suppress leading zeros in such a case.
Provides compatibility with other ACPI implementations.
Link: https://github.com/acpica/acpica/commit/f2cb44f6
Signed-off-by: Armin Wolf <W_Armin@gmx.de>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
ACPICA commit 1280045754264841b119a5ede96cd005bc09b5a7
If acpi_ps_get_next_field() fails, the previously created field list
needs to be properly disposed before returning the status code.
Link: https://github.com/acpica/acpica/commit/12800457
Signed-off-by: Armin Wolf <W_Armin@gmx.de>
[ rjw: Rename local variable to avoid compiler confusion ]
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
ACPICA commit f0776a465cc2c20393bec534c16bdee4a78f7bb7
explicitly allow QWord address space description type
to be 0xA to indicate it refers to a Platform
Communication channel
IAW ACPI_ECR_PCC_DESCRIPTORS_CF_V2
https://bugzilla.tianocore.org/show_bug.cgi?id=4594
An entity in a DSDT or in SSDTs that requires
a platform communication channel table (PCCT) entry
to communicate with a remote service will have a single
value that is the index of the entry in the PCCT.
This data type with have a resource_type value of 0xA.
This value indicates that the type shares the same
footprint as a Dword_space section.
Link: https://github.com/acpica/acpica/commit/f0776a46
Signed-off-by: Adam Young <ayoung@amperecomputing.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
ACPICA commit 129b75516fc49fe1fd6b8c5798f86c13854630b3
Stop nagging user about every Stall() that violates the spec
On my Dell XPS 15 7590 I get hundreds of these warnings after few hours of
uptime:
$ dmesg | grep "fix the firmware" | wc -l
261
I cannot fix the firmware and I doubt that Dell cares about 4 year old
laptop either
Fixes: ace8f1c54a ("ACPICA: executer/exsystem: Inform users about ACPI spec violation")
Link: https://github.com/acpica/acpica/commit/129b7551
Signed-off-by: Vasily Khoruzhick <anarsoul@gmail.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
ACPICA commit 49fe4f25483feec2f685b204ef19e28d92979e95
In Haiku, semaphores are represented by integers, not pointers.
So, we can't use NULL as the invalid/destroyed value, the correct value
is -1. Introduce a platform overridable define to allow this.
Fixes#162 (which was closed after coming to the conclusion that this
should be done, but the change was never done).
Link: https://github.com/acpica/acpica/commit/49fe4f25
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
When acpi_evaluate_dsm() fails, the warning message lacks the rev
and func information which is available and helpful.
For example, iwlwifi would make _DSM queries for lari config,
and when it fails, all warning messages are all the same:
ACPI: \: failed to evaluate _DSM bf0212f2-788f-c64d-a5b3-1f738e285ade (0x1001)
ACPI: \: failed to evaluate _DSM bf0212f2-788f-c64d-a5b3-1f738e285ade (0x1001)
ACPI: \: failed to evaluate _DSM bf0212f2-788f-c64d-a5b3-1f738e285ade (0x1001)
ACPI: \: failed to evaluate _DSM bf0212f2-788f-c64d-a5b3-1f738e285ade (0x1001)
ACPI: \: failed to evaluate _DSM bf0212f2-788f-c64d-a5b3-1f738e285ade (0x1001)
ACPI: \: failed to evaluate _DSM bf0212f2-788f-c64d-a5b3-1f738e285ade (0x1001)
ACPI: \: failed to evaluate _DSM bf0212f2-788f-c64d-a5b3-1f738e285ade (0x1001)
ACPI: \: failed to evaluate _DSM bf0212f2-788f-c64d-a5b3-1f738e285ade (0x1001)
With this change, the warnings would be more informative:
ACPI: \: failed to evaluate _DSM bf0212f2-788f-c64d-a5b3-1f738e285ade rev:0 func:1 (0x1001)
ACPI: \: failed to evaluate _DSM bf0212f2-788f-c64d-a5b3-1f738e285ade rev:0 func:6 (0x1001)
ACPI: \: failed to evaluate _DSM bf0212f2-788f-c64d-a5b3-1f738e285ade rev:0 func:7 (0x1001)
ACPI: \: failed to evaluate _DSM bf0212f2-788f-c64d-a5b3-1f738e285ade rev:0 func:8 (0x1001)
ACPI: \: failed to evaluate _DSM bf0212f2-788f-c64d-a5b3-1f738e285ade rev:0 func:3 (0x1001)
ACPI: \: failed to evaluate _DSM bf0212f2-788f-c64d-a5b3-1f738e285ade rev:0 func:9 (0x1001)
ACPI: \: failed to evaluate _DSM bf0212f2-788f-c64d-a5b3-1f738e285ade rev:0 func:10 (0x1001)
ACPI: \: failed to evaluate _DSM bf0212f2-788f-c64d-a5b3-1f738e285ade rev:0 func:12 (0x1001)
Signed-off-by: David Wang <00107082@163.com>
Link: https://patch.msgid.link/20240826233437.19632-1-00107082@163.com
[ rjw: Subject and changelog edits ]
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
There are 2G and 4G RAM versions of the Lenovo Yoga Tab 3 X90F and it
turns out that the 2G version has a DMI product name of
"CHERRYVIEW D1 PLATFORM" where as the 4G version has
"CHERRYVIEW C0 PLATFORM". The sys-vendor + product-version check are
unique enough that the product-name check is not necessary.
Drop the product-name check so that the existing DMI match for the 4G
RAM version also matches the 2G RAM version.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Link: https://patch.msgid.link/20240825132322.6776-2-hdegoede@redhat.com
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
There are 2G and 4G RAM versions of the Lenovo Yoga Tab 3 X90F and it
turns out that the 2G version has a DMI product name of
"CHERRYVIEW D1 PLATFORM" where as the 4G version has
"CHERRYVIEW C0 PLATFORM". The sys-vendor + product-version check are
unique enough that the product-name check is not necessary.
Drop the product-name check so that the existing DMI match for the 4G
RAM version also matches the 2G RAM version.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Link: https://patch.msgid.link/20240825132322.6776-1-hdegoede@redhat.com
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Merge thermal core updates for 6.12 which, among other things, rework
the thermal driver interface for binding cooling devices to thermal
zones and add a thermal core testing module:
- Update some thermal drivers to eliminate thermal_zone_get_trip()
calls from them and get rid of that function (Rafael Wysocki).
- Update the thermal sysfs code to store trip point attributes in trip
descriptors and get to trip points via attribute pointers (Rafael
Wysocki).
- Move the computation of the low and high boundaries for
thermal_zone_set_trips() to __thermal_zone_device_update() (Daniel
Lezcano).
- Introduce a debugfs-based facility for thermal core testing (Rafael
Wysocki).
- Replace the thermal zone .bind() and .unbind() callbacks for binding
cooling devices to thermal zones with one .should_bind() callback
used for deciding whether or not a given cooling devices should be
bound to a given trip point in a given thermal zone (Rafael Wysocki).
- Eliminate code that has no more users after the other changes, drop
some redundant checks from the thermal core and clean it up (Rafael
Wysocki).
- Fix rounding of delay jiffies in the thermal core (Rafael Wysocki).
* thermal-core: (31 commits)
thermal: core: Drop tz field from struct thermal_instance
thermal: core: Drop redundant checks from thermal_bind_cdev_to_trip()
thermal: core: Rename cdev-to-thermal-zone bind/unbind functions
thermal: core: Fix rounding of delay jiffies
thermal: core: Clean up trip bind/unbind functions
thermal: core: Drop unused bind/unbind functions and callbacks
thermal/of: Use the .should_bind() thermal zone callback
thermal: imx: Use the .should_bind() thermal zone callback
mlxsw: core_thermal: Use the .should_bind() thermal zone callback
platform/x86: acerhdf: Use the .should_bind() thermal zone callback
thermal: core: Unexport thermal_bind_cdev_to_trip() and thermal_unbind_cdev_from_trip()
thermal: ACPI: Use the .should_bind() thermal zone callback
thermal: core: Introduce .should_bind() thermal zone callback
thermal: core: Move thermal zone locking out of bind/unbind functions
thermal: sysfs: Use the dev argument in instance-related show/store
thermal: core: Drop redundant thermal instance checks
thermal: core: Rearrange checks in thermal_bind_cdev_to_trip()
thermal: core: Fold two functions into their respective callers
thermal: Introduce a debugfs-based testing facility
thermal/core: Compute low and high boundaries in thermal_zone_device_update()
...
RISC-V interrupt controllers for wired interrupts are platform devices
and hence their driver will be probed late. Also, APLIC which is one
such interrupt controller can not be probed early since it needs MSI
services. This needs a probing order between the interrupt controller
driver and the device drivers.
_DEP is typically used to indicate such dependencies. However, the
dependency may be already available like GSI mapping. Hence, instead of
an explicit _DEP, architecture can find the implicit dependencies and
add to the dependency list.
For RISC-V, add the dependencies for below use cases.
1) For devices which has IRQ resource, find out the interrupt controller
using GSI number map and add the dependency.
2) For PCI host bridges:
a) If _PRT indicate PCI link devices, add dependency on the link
device.
b) If _PRT indicates GSI, find out the interrupt controller
using GSI number map and add the dependency.
Signed-off-by: Sunil V L <sunilvl@ventanamicro.com>
Tested-by: Björn Töpel <bjorn@rivosinc.com>
Link: https://patch.msgid.link/20240812005929.113499-13-sunilvl@ventanamicro.com
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
On RISC-V platforms, the RINTC structures should be probed before any
other interrupt controller structures and IMSIC before APLIC. This order
is established by using MADT sub table types which are ordered in the
incremental order from the RINTC. So, add the architecture function for
RISC-V to reorder the interrupt controller probing as per the hierarchy
like below.
ACPI_MADT_TYPE_RINTC = 24,
ACPI_MADT_TYPE_IMSIC = 25,
ACPI_MADT_TYPE_APLIC = 26,
ACPI_MADT_TYPE_PLIC = 27
This means processing all RINTC structures (in the order of appearance
in MADT), followed by IMSIC strucutre and then all APLIC/PLIC
structures.
Signed-off-by: Sunil V L <sunilvl@ventanamicro.com>
Tested-by: Björn Töpel <bjorn@rivosinc.com>
Link: https://patch.msgid.link/20240812005929.113499-11-sunilvl@ventanamicro.com
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
RISC-V platforms need to use dependencies between PCI host bridge, Link
devices and the interrupt controllers to ensure probe order. The
dependency is like below.
Interrupt controller <-- Link Device <-- PCI Host bridge.
If there is no dependency between Link device and PCI Host Bridge,
then PCI devices may be probed prior to Link devices. If a PCI
device is probed before its Link device, we won't be able to find
its INTx mapping.
So, add the link device's HID to dependency honor list and clear the
dependency after probe is done so that the dependent devices are
unblocked to probe.
Signed-off-by: Sunil V L <sunilvl@ventanamicro.com>
Tested-by: Björn Töpel <bjorn@rivosinc.com>
Link: https://patch.msgid.link/20240812005929.113499-9-sunilvl@ventanamicro.com
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Unlike OF framework, the irqchip probe using IRQCHIP_ACPI_DECLARE has no
order defined. Depending on the Makefile is not a good idea. So,
usually it is worked around by mandating only root interrupt controller
probed using IRQCHIP_ACPI_DECLARE and other interrupt controllers are
probed via cascade mechanism.
However, this is also not a clean solution because if there are multiple
root controllers (ex: RINTC in RISC-V which is per CPU) which need to be
probed first, then the cascade will happen for every root controller.
So, introduce an architecture specific weak function
arch_sort_irqchip_probe() to order the probing of the interrupt
controllers which can be implemented by different architectures as per
their interrupt controller hierarchy.
Signed-off-by: Sunil V L <sunilvl@ventanamicro.com>
Tested-by: Björn Töpel <bjorn@rivosinc.com>
Link: https://patch.msgid.link/20240812005929.113499-3-sunilvl@ventanamicro.com
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
It used to be that the MacbookPro9,2 used its native intel backlight
device until the following commit was introduced:
commit b1d36e73cc ("drm/i915: Don't register backlight when another
backlight should be used (v2)")
This commit forced this model to use its firmware acpi_video backlight
device instead.
That worked fine until an additional commit was added:
commit 92714006eb ("drm/i915/backlight: Do not bump min brightness
to max on enable")
That commit uncovered a bug in the MacbookPro 9,2's acpi_video
backlight firmware; the backlight does not come back up after resume.
Add DMI quirk to select the working native intel interface instead
so that the backlight successfully comes back up after resume.
Fixes: 92714006eb ("drm/i915/backlight: Do not bump min brightness to max on enable")
Signed-off-by: Esther Shimanovich <eshimanovich@chromium.org>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Link: https://patch.msgid.link/20240806-acpi-video-quirk-v1-1-369d8f7abc59@chromium.org
[ rjw: Subject and changelog edits ]
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Make the ACPI thermal zone driver use the .should_bind() thermal zone
callback to provide the thermal core with the information on whether or
not to bind the given cooling device to the given trip point in the
given thermal zone. If it returns 'true', the thermal core will bind
the cooling device to the trip and the corresponding unbinding will be
taken care of automatically by the core on the removal of the involved
thermal zone or cooling device.
This replaces the .bind() and .unbind() thermal zone callbacks which
allows the code to be simplified quite significantly while providing
the same functionality.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Zhang Rui <rui.zhang@intel.com>
Reviewed-by: Daniel Lezcano <daniel.lezcano@linaro.org>
Link: https://patch.msgid.link/1812827.VLH7GnMWUR@rjwysocki.net
Since thermal_bind_cdev_to_trip() and thermal_unbind_cdev_from_trip()
acquire the thermal zone lock, the locking rules for their callers get
complicated. In particular, the thermal zone lock cannot be acquired
in any code path leading to one of these functions even though it might
be useful to do so.
To address this, remove the thermal zone locking from both these
functions, add lockdep assertions for the thermal zone lock to both
of them and make their callers acquire the thermal zone lock instead.
No intentional functional impact.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Zhang Rui <rui.zhang@intel.com>
Reviewed-by: Daniel Lezcano <daniel.lezcano@linaro.org>
Link: https://patch.msgid.link/3837835.kQq0lBPeGt@rjwysocki.net
Dell All In One (AIO) models released after 2017 may use a backlight
controller board connected to an UART.
In DSDT this uart port will be defined as:
Name (_HID, "DELL0501")
Name (_CID, EisaId ("PNP0501")
The Dell OptiPlex 7760 AIO has an ACPI device for one if its UARTs with
the above _HID + _CID. Loading the dell-uart-backlight driver shows that
there actually is a backlight controller board attached to the UART,
which reports a firmware version of "G&MX01-V15".
But the backlight controller board does not actually control the backlight
brightness and the GPU's native backlight control method does work.
Add a quirk to use the GPU's native backlight control method on this model.
Fixes: 484bae9e4d ("platform/x86: Add new Dell UART backlight driver")
Closes: https://bugzilla.redhat.com/show_bug.cgi?id=2303936
Cc: All applicable <stable@vger.kernel.org>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Andy Shevchenko <andy@kernel.org>
Link: https://patch.msgid.link/20240814190159.15650-4-hdegoede@redhat.com
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Dell All In One (AIO) models released after 2017 use a backlight
controller board connected to an UART.
In DSDT this uart port will be defined as:
Name (_HID, "DELL0501")
Name (_CID, EisaId ("PNP0501")
Commit 484bae9e4d ("platform/x86: Add new Dell UART backlight driver")
has added support for this, but I neglected to tie this into
acpi_video_get_backlight_type().
Now the first AIO has turned up which has not only the DSDT bits for this,
but also an actual controller attached to the UART, yet it is not using
this controller for backlight control.
Add support to acpi_video_get_backlight_type() for a new dell_uart
backlight type. So that the existing infra to override the backlight
control method on the commandline or with DMI quirks can be used.
Fixes: 484bae9e4d ("platform/x86: Add new Dell UART backlight driver")
Cc: All applicable <stable@vger.kernel.org>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Andy Shevchenko <andy@kernel.org>
Link: https://patch.msgid.link/20240814190159.15650-2-hdegoede@redhat.com
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Commit 60fa6ae6e6 ("ACPI: EC: Install address space handler at the
namespace root") caused _REG methods for EC operation regions outside
the EC device scope to be evaluated which on some systems leads to the
evaluation of _REG methods in the scopes of device objects representing
devices that are not present and not functional according to the _STA
return values. Some of those device objects represent EC "alternatives"
and if _REG is evaluated for their operation regions, the platform
firmware may be confused and the platform may start to behave
incorrectly.
To avoid this problem, only evaluate _REG for EC operation regions
located in the scopes of device objects representing known-to-be-present
devices.
For this purpose, partially revert commit 60fa6ae6e6 and trigger the
evaluation of _REG for EC operation regions from acpi_bus_attach() for
the known-valid devices.
Fixes: 60fa6ae6e6 ("ACPI: EC: Install address space handler at the namespace root")
Link: https://lore.kernel.org/linux-acpi/1f76b7e2-1928-4598-8037-28a1785c2d13@redhat.com
Link: https://bugzilla.redhat.com/show_bug.cgi?id=2298938
Link: https://bugzilla.redhat.com/show_bug.cgi?id=2302253
Reported-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Cc: All applicable <stable@vger.kernel.org>
Link: https://patch.msgid.link/23612351.6Emhk5qWAg@rjwysocki.net
