IF YOU WOULD LIKE TO GET AN ACCOUNT, please write an
email to Administrator. User accounts are meant only to access repo
and report issues and/or generate pull requests.
This is a purpose-specific Git hosting for
BaseALT
projects. Thank you for your understanding!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
This driver allows user space to fetch telemetry data from the
firmware with the help of the Platform Firmware Runtime Telemetry
interface.
Both PFRU and PFRT are based on ACPI _DSM interfaces located under
special device objects in the ACPI Namespace, but these interfaces
are different from each other, so it is better to provide a separate
driver from each of them, even though they share some common
definitions and naming conventions.
Tested-by: Hongyu Ning <hongyu.ning@intel.com>
Signed-off-by: Chen Yu <yu.c.chen@intel.com>
[ rjw: Subject and changelog edits ]
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Introduce the pfr_update driver which can be used for Platform Firmware
Runtime code injection and driver update [1].
The user is expected to provide the EFI capsule, and pass it to the
driver by writing the capsule to a device special file. The capsule
is transferred by the driver to the platform firmware with the help
of an ACPI _DSM method under the special ACPI Platform Firmware
Runtime Update device (INTC1080), and the actual firmware update is
carried out by the low-level Management Mode code in the platform
firmware.
This change allows certain pieces of the platform firmware to be
updated on the fly while the system is running (runtime) without the
need to restart it, which is key in the cases when the system needs to
be available 100% of the time and it cannot afford the downtime related
to restarting it, or when the work carried out by the system is
particularly important, so it cannot be interrupted, and it is not
practical to wait until it is complete.
Link: https://uefi.org/sites/default/files/resources/Intel_MM_OS_Interface_Spec_Rev100.pdf # [1]
Tested-by: Hongyu Ning <hongyu.ning@intel.com>
Signed-off-by: Chen Yu <yu.c.chen@intel.com>
[ rjw: Subject and changelog edits ]
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
ACPICA commit 86c919d2bad08491fc91ffa53e9b169092de8622
Repaired with casts.
Link: https://github.com/acpica/acpica/commit/86c919d2
Signed-off-by: Bob Moore <robert.moore@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
ACPICA commit ff803279dde7a3e068a6a698d8c69503cd159ad7
To simply return (AE_BAD_PARAMETER); to fix compilation on MSVC.
Link: https://github.com/acpica/acpica/commit/ff803279
Signed-off-by: Bob Moore <robert.moore@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
ACPICA commit 3dd7e1f3996456ef81bfe14cba29860e8d42949e
According to ACPI 6.4, Section 16.2, the CPU cache flushing is
required on entering to S1, S2, and S3, but the ACPICA code
flushes the CPU cache regardless of the sleep state.
Blind cache flush on entering S5 causes problems for TDX.
Flushing happens with WBINVD that is not supported in the TDX
environment.
TDX only supports S5 and adjusting ACPICA code to conform to the
spec more strictly fixes the issue.
Link: https://github.com/acpica/acpica/commit/3dd7e1f3
Signed-off-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
[ rjw: Subject and changelog edits ]
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Bob Moore <robert.moore@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
ACPICA commit 55526e8a6133cbf5a9cc0fb75a95dbbac6eb98e6
PCC Opregion added in ACPIC 6.3 requires special context data similar
to GPIO and Generic Serial Bus as it needs to know the internal PCC
buffer and its length as well as the PCC channel index when the opregion
handler is being executed by the OSPM.
Lets add support for the special context data needed by PCC Opregion.
Link: https://github.com/acpica/acpica/commit/55526e8a
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
Signed-off-by: Bob Moore <robert.moore@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
ACPICA commit 41be6afacfdaec2dba3a5ed368736babc2a7aa5c
With the PCC Opregion in the firmware and we are hitting below kernel crash:
-->8
Unable to handle kernel NULL pointer dereference at virtual address 0000000000000010
Workqueue: pm pm_runtime_work
pstate: 80000005 (Nzcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
pc : __memcpy+0x54/0x260
lr : acpi_ex_write_data_to_field+0xb8/0x194
Call trace:
__memcpy+0x54/0x260
acpi_ex_store_object_to_node+0xa4/0x1d4
acpi_ex_store+0x44/0x164
acpi_ex_opcode_1A_1T_1R+0x25c/0x508
acpi_ds_exec_end_op+0x1b4/0x44c
acpi_ps_parse_loop+0x3a8/0x614
acpi_ps_parse_aml+0x90/0x2f4
acpi_ps_execute_method+0x11c/0x19c
acpi_ns_evaluate+0x1ec/0x2b0
acpi_evaluate_object+0x170/0x2b0
acpi_device_set_power+0x118/0x310
acpi_dev_suspend+0xd4/0x180
acpi_subsys_runtime_suspend+0x28/0x38
__rpm_callback+0x74/0x328
rpm_suspend+0x2d8/0x624
pm_runtime_work+0xa4/0xb8
process_one_work+0x194/0x25c
worker_thread+0x260/0x49c
kthread+0x14c/0x30c
ret_from_fork+0x10/0x20
Code: f9000006 f81f80a7 d65f03c0 361000c2 (b9400026)
---[ end trace 24d8a032fa77b68a ]---
The reason for the crash is that the PCC channel index passed via region.address
in acpi_ex_store_object_to_node is interpreted as the channel subtype
incorrectly.
Assuming the PCC op_region support is not used by any other type, let us
remove the subtype check as the AML has no access to the subtype information.
Once we remove it, the kernel crash disappears and correctly complains about
missing PCC Opregion handler.
ACPI Error: No handler for Region [PFRM] ((____ptrval____)) [PCC] (20210730/evregion-130)
ACPI Error: Region PCC (ID=10) has no handler (20210730/exfldio-261)
ACPI Error: Aborting method \_SB.ETH0._PS3 due to previous error (AE_NOT_EXIST) (20210730/psparse-531)
Link: https://github.com/acpica/acpica/commit/41be6afa
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
Signed-off-by: Bob Moore <robert.moore@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
ACPICA commit d984f12041392fa4156b52e2f7e5c5e7bc38ad9e
If Operand[0] is a reference of the ACPI_REFCLASS_REFOF class,
acpi_ex_opcode_1A_0T_1R () calls acpi_ns_get_attached_object () to
obtain return_desc which may require additional resolution with
the help of acpi_ex_read_data_from_field (). If the latter fails,
the reference counter of the original return_desc is decremented
which is incorrect, because acpi_ns_get_attached_object () does not
increment the reference counter of the object returned by it.
This issue may lead to premature deletion of the attached object
while it is still attached and a use-after-free and crash in the
host OS. For example, this may happen when on evaluation of ref_of()
a local region field where there is no registered handler for the
given Operation Region.
Fix it by making acpi_ex_opcode_1A_0T_1R () return Status right away
after a acpi_ex_read_data_from_field () failure.
Link: https://github.com/acpica/acpica/commit/d984f120
Link: https://github.com/acpica/acpica/pull/685
Reported-by: Lenny Szubowicz <lszubowi@redhat.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Bob Moore <robert.moore@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
ACPICA commit c11af67d8f7e3d381068ce7771322f2b5324d687
If original_count is 0 in acpi_ut_update_ref_count (),
acpi_ut_delete_internal_obj () is invoked for the target object, which is
incorrect, because that object has been deleted once already and the
memory allocated to store it may have been reclaimed and allocated
for a different purpose by the host OS. Moreover, a confusing debug
message following the "Reference Count is already zero, cannot
decrement" warning is printed in that case.
To fix this issue, make acpi_ut_update_ref_count () return after finding
that original_count is 0 and printing the above warning.
Link: https://github.com/acpica/acpica/commit/c11af67d
Link: https://github.com/acpica/acpica/pull/652
Reported-by: Mark Asselstine <mark.asselstine@windriver.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Bob Moore <robert.moore@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
ACPICA commit 6bb72909c1e3d415aee214104a01bc9834b2d4ce
Since the Signature member is accessed through an struct acpi_table_header, the
pointer to it is only to a 4-char array, and so trying to read past the
4th character, as will be done when it is an RSDP, reads beyond the
bounds of the accessed member. On CHERI, and thus Arm's experimental
Morello prototype architecture, pointers are represented as
capabilities, which are unforgeable bounded pointers, providing
always-on fine-grained spatial memory safety. By default, subobject
bounds enforcement is not enabled, only bounds on allocations, but it is
enabled in the cheri_BSD (a port of free_BSD) kernel as intra-object
overflow attacks are common on operating system kernels, and so this
overflow is detected there and traps.
Link: https://github.com/acpica/acpica/commit/6bb72909
Signed-off-by: Bob Moore <robert.moore@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
ACPICA commit dfa3feffa8f760b686207d09dc880cd2f26c72af
Currently the pointer to the table is cast to acpi_physical_address and
later cast back to a pointer to be dereferenced. Whether or not this is
supported is implementation-defined.
On CHERI, and thus Arm's experimental Morello prototype architecture,
pointers are represented as capabilities, which are unforgeable bounded
pointers, providing always-on fine-grained spatial memory safety. This
means that any pointer cast to a plain integer will lose all its
associated metadata, and when cast back to a pointer it will give a
null-derived pointer (one that has the same metadata as null but an
address equal to the integer) that will trap on any dereference. As a
result, this is an implementation where acpi_physical_address cannot be
used as a hack to store real pointers.
Thus, alter the lifecycle of table descriptors. Internal physical tables
keep the current behaviour where only the address is set on install, and
the pointer is set on acquire. Virtual tables (internal and external)
now store the pointer on initialisation and use that on acquire (which
will redundantly set *table_ptr to itself, but changing that is both
unnecessary and overly complicated as acpi_tb_acquire_table is called with
both a pointer to a variable and a pointer to Table->Pointer itself).
This requires propagating the (possible) table pointer everywhere in
order to make sure pointers make it through to acpi_tb_acquire_temp_table,
which requires a change to the acpi_install_table interface. Instead of
taking an ACPI_PHYSADDR_TYPE and a boolean indicating whether it's
physical or virtual, it is now split into acpi_install_table (that takes
an external virtual table pointer) and acpi_install_physical_table (that
takes an ACPI_PHYSADDR_TYPE for an internal physical table address).
This also has the benefit of providing a cleaner API.
Link: https://github.com/acpica/acpica/commit/dfa3feff
Signed-off-by: Bob Moore <robert.moore@intel.com>
[ rjw: Adjust the code in tables.c to match interface changes ]
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
ACPICA commit d9eb82bd7515989f0b29d79deeeb758db4d6529c
Currently the pointer to the table is cast to acpi_physical_address and
later cast back to a pointer to be dereferenced. Whether or not this is
supported is implementation-defined.
On CHERI, and thus Arm's experimental Morello prototype architecture,
pointers are represented as capabilities, which are unforgeable bounded
pointers, providing always-on fine-grained spatial memory safety. This
means that any pointer cast to a plain integer will lose all its
associated metadata, and when cast back to a pointer it will give a
null-derived pointer (one that has the same metadata as null but an
address equal to the integer) that will trap on any dereference. As a
result, this is an implementation where acpi_physical_address cannot be
used as a hack to store real pointers.
Thus, add a new field to struct acpi_object_region to store the pointer for
table regions, and propagate it to acpi_ex_data_table_space_handler via the
region context, to use a more portable implementation that supports
CHERI.
Link: https://github.com/acpica/acpica/commit/d9eb82bd
Signed-off-by: Bob Moore <robert.moore@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Currently it's too hard to read the _CPC structure as it's commented.
Reshuffle indentation and style to make it readable.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Strictly speaking the comparison between guid_t and raw buffer
is not correct. Import GUID to variable of guid_t type and then
compare.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://lore.kernel.org/r/20211213204632.56735-1-andriy.shevchenko@linux.intel.com
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
Some systems (e.g. Hyper-V guests) have all their memory marked as
hotpluggable in SRAT. acpi_numa_memory_affinity_init(), however,
ignores all such regions when !CONFIG_MEMORY_HOTPLUG and this is
unfortunate as memory affinity (NUMA) information gets lost.
'Hot Pluggable' flag in SRAT only means that "system hardware supports
hot-add and hot-remove of this memory region", it doesn't prevent
memory from being cold-plugged there.
Ignore 'Hot Pluggable' bit instead of skipping the whole memory
affinity information when !CONFIG_MEMORY_HOTPLUG.
Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
ACPICA code takes care about cache flushing on S1/S2/S3 in
acpi_hw_extended_sleep() and acpi_hw_legacy_sleep().
acpi_suspend_enter() calls into ACPICA code via acpi_enter_sleep_state()
for S1 or x86_acpi_suspend_lowlevel() for S3.
acpi_sleep_prepare() call tree:
__acpi_pm_prepare()
acpi_pm_prepare()
acpi_suspend_ops::prepare_late()
acpi_hibernation_ops::pre_snapshot()
acpi_hibernation_ops::prepare()
acpi_suspend_begin_old()
acpi_suspend_begin_old::begin()
acpi_hibernation_begin_old()
acpi_hibernation_ops_old::acpi_hibernation_begin_old()
acpi_power_off_prepare()
pm_power_off_prepare()
Hibernation (S4) and Power Off (S5) don't require cache flushing, so
the only interesting callsites are acpi_suspend_ops::prepare_late()
and acpi_suspend_begin_old::begin(). Both of them have cache flush
on ->enter() operation in acpi_suspend_enter().
Remove redundant ACPI_FLUSH_CPU_CACHE() in acpi_sleep_prepare() and
acpi_suspend_enter().
Signed-off-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
According to ACPI 6.4, Section 8.2, CPU cache flushing required on
entering the C3 power state.
Avoid flushing the cache on entering other C-states.
Signed-off-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
[ rjw: Changelog edits ]
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Modify the ACPI code to use acpi_fetch_acpi_dev() instead of
acpi_bus_get_device() where applicable.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Introduce acpi_fetch_acpi_dev() as a more reasonable replacement for
acpi_bus_get_device() and modify the code in scan.c to use it instead
of the latter.
No expected functional impact.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
This branch contains 5.16-rc1 + the pending ACPI/i2c, tps68570 platform_data
and INT3472 driver patches.
-----BEGIN PGP SIGNATURE-----
iQFIBAABCAAyFiEEuvA7XScYQRpenhd+kuxHeUQDJ9wFAmG6YLQUHGhkZWdvZWRl
QHJlZGhhdC5jb20ACgkQkuxHeUQDJ9zwGwf8Csb4wXyc3duBlnX/9jO9REDVKTN9
HhmU2KQm29g10dN2nlFXEOG16xAy8zt3BE7QwniL/R5sUsKTCAEugY8Aqq/4+lFA
vTU+YR9YqZFmEDGMfDngHeh9ZvSWIJS7IEXthxCkgGVhrd2Wl50jKTjVyq1RIDKv
a7B4fOhguFv95xRlnXK+yoVUU7zZPWAgxyCqV0E0JEi8aWE8Y483IRCzcDEyJeDa
HkgZLVwD9l3WQ4uZllVg1q5jfSprHwBa8dFxgcd6mOOYaKowiJ+GjnvnXOto5X72
zsODBJH15VzfVXF5cAqIvzN6nAFR8Mxieei+21iFyUD/Ps1vfWlodFHH2w==
=Q1N9
-----END PGP SIGNATURE-----
Merge tag 'platform-drivers-x86-int3472-1' of git://git.kernel.org/pub/scm/linux/kernel/git/pdx86/platform-drivers-x86 into media_tree
Signed tag for the immutable platform-drivers-x86-int3472 branch
This branch contains 5.16-rc1 + the pending ACPI/i2c, tps68570 platform_data
and INT3472 driver patches.
* tag 'platform-drivers-x86-int3472-1' of git://git.kernel.org/pub/scm/linux/kernel/git/pdx86/platform-drivers-x86:
platform/x86: int3472: Deal with probe ordering issues
platform/x86: int3472: Pass tps68470_regulator_platform_data to the tps68470-regulator MFD-cell
platform/x86: int3472: Pass tps68470_clk_platform_data to the tps68470-regulator MFD-cell
platform/x86: int3472: Add get_sensor_adev_and_name() helper
platform/x86: int3472: Split into 2 drivers
platform_data: Add linux/platform_data/tps68470.h file
i2c: acpi: Add i2c_acpi_new_device_by_fwnode() function
i2c: acpi: Use acpi_dev_ready_for_enumeration() helper
ACPI: delay enumeration of devices with a _DEP pointing to an INT3472 device
Add AEST to the list of known ACPI table signatures to allow the
kernel to recognize it when upgrading tables via initrd.
Signed-off-by: Shuuichirou Ishii <ishii.shuuichir@fujitsu.com>
Acked-by: Hanjun Guo <guohanjun@huawei.com>
[ rjw: New subject and changelog ]
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
The clk and regulator frameworks expect clk/regulator consumer-devices
to have info about the consumed clks/regulators described in the device's
fw_node.
To work around cases where this info is not present in the firmware tables,
which is often the case on x86/ACPI devices, both frameworks allow the
provider-driver to attach info about consumers to the clks/regulators
when registering these.
This causes problems with the probe ordering wrt drivers for consumers
of these clks/regulators. Since the lookups are only registered when the
provider-driver binds, trying to get these clks/regulators before then
results in a -ENOENT error for clks and a dummy regulator for regulators.
One case where we hit this issue is camera sensors such as e.g. the OV8865
sensor found on the Microsoft Surface Go. The sensor uses clks, regulators
and GPIOs provided by a TPS68470 PMIC which is described in an INT3472
ACPI device. There is special platform code handling this and setting
platform_data with the necessary consumer info on the MFD cells
instantiated for the PMIC under: drivers/platform/x86/intel/int3472.
For this to work properly the ov8865 driver must not bind to the I2C-client
for the OV8865 sensor until after the TPS68470 PMIC gpio, regulator and
clk MFD cells have all been fully setup.
The OV8865 on the Microsoft Surface Go is just one example, all X86
devices using the Intel IPU3 camera block found on recent Intel SoCs
have similar issues where there is an INT3472 HID ACPI-device, which
describes the clks and regulators, and the driver for this INT3472 device
must be fully initialized before the sensor driver (any sensor driver)
binds for things to work properly.
On these devices the ACPI nodes describing the sensors all have a _DEP
dependency on the matching INT3472 ACPI device (there is one per sensor).
This allows solving the probe-ordering problem by delaying the enumeration
(instantiation of the I2C-client in the ov8865 example) of ACPI-devices
which have a _DEP dependency on an INT3472 device.
The new acpi_dev_ready_for_enumeration() helper used for this is also
exported because for devices, which have the enumeration_by_parent flag
set, the parent-driver will do its own scan of child ACPI devices and
it will try to enumerate those during its probe(). Code doing this such
as e.g. the i2c-core-acpi.c code must call this new helper to ensure
that it too delays the enumeration until all the _DEP dependencies are
met on devices which have the new honor_deps flag set.
Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Link: https://lore.kernel.org/r/20211203102857.44539-2-hdegoede@redhat.com
According to ACPI 6.4, Section 16.2, the CPU cache flushing is
required on entering to S1, S2, and S3.
No need to flush the caches during hibernation (S4).
Signed-off-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
[ rjw: Subject and changelog edits ]
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Theoretically, when the hardware signature in FACS changes, the OS
is supposed to gracefully decline to attempt to resume from S4:
"If the signature has changed, OSPM will not restore the system
context and can boot from scratch"
In practice, Windows doesn't do this and many laptop vendors do allow
the signature to change especially when docking/undocking, so it would
be a bad idea to simply comply with the specification by default in the
general case.
However, there are use cases where we do want the compliant behaviour
and we know it's safe. Specifically, when resuming virtual machines where
we know the hypervisor has changed sufficiently that resume will fail.
We really want to be able to *tell* the guest kernel not to try, so it
boots cleanly and doesn't just crash. This patch provides a way to opt
in to the spec-compliant behaviour on the command line.
A follow-up patch may do this automatically for certain "known good"
machines based on a DMI match, or perhaps just for all hypervisor
guests since there's no good reason a hypervisor would change the
hardware_signature that it exposes to guests *unless* it wants them
to obey the ACPI specification.
Signed-off-by: David Woodhouse <dwmw@amazon.co.uk>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
On some devices with a X-Powers AXP288 PMIC the LPAT tables in the ACPI
node for the AXP288 PMIC for some reason only describe a small temperature
range, e.g. 27° - 37° Celcius (assuming the entries are in millidegrees).
When the tablet is idle in a room at 21° degrees this is causing values
outside the LPAT table to be read, causing e.g. the following 2 errors
to get spammed to the logs every 4 seconds! :
[ 7512.791316] ACPI Error: AE_ERROR, Returned by Handler for [UserDefinedRegion] (20210930/evregion-281)
[ 7512.791611] ACPI Error: Aborting method \_SB.SXP1._TMP due to previous error (AE_ERROR) (20210930/psparse-529)
Fix this by clamping the raw value to the LPAT table range before
passing it to acpi_lpat_raw_to_temp().
Note clamping has been chosen rather then extrapolating because it is
unknown how other parts of the ACPI tables will respond to temperature
values outside of the LPAT range.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
The LPAT tables used in the DSDT for some PMICs require special handling,
allow the PMIC OpRegion drivers to provide an alternative implementation
by adding a lpat_raw_to_temp function pointer to struct pmic_table;
and initialize this to the default acpi_lpat_raw_to_temp function
for all PMICs.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
The struct intel_pmic_opregion_data declarations never change,
constify them all.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Using write_support=1 with the ec_sys module changes the mode of the
"io" debugfs file to 0600. This will cause any attempts to access it under
a kernel in lockdown mode to return -EPERM, which makes the entire ec_sys
module unusable.
Use the special module_param_hw() macro for module parameters which
may not be used while in lockdown mode, to avoid this.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Move acpi_ec_create_query() after acpi_ec_event_processor(), drop the
no longer needed forward declaration of the latter, and eliminate
acpi_ec_delete_query() which isn't really necessary.
No intentional functional impact.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
The EC driver uses a relatively simple state machine for the event
work handling, but it is not really straightforward to figure out.
The states are as follows:
"Ready": The event handling work can be submitted.
In this state, the EC_FLAGS_QUERY_PENDING flag is clear.
"In progress": The event handling work is pending or is being
processed. It cannot be submitted again.
In ths state, the EC_FLAGS_QUERY_PENDING flag is set and both the
events_to_process count is nonzero and the EC_FLAGS_QUERY_GUARDING
flag is clear.
"Complete": The event handling work has been completed, but it still
cannot be submitted again.
In ths state, the EC_FLAGS_QUERY_PENDING flag is set and the
events_to_process count is zero or the EC_FLAGS_QUERY_GUARDING
flag is set.
The state changes from "Ready" to "In progress" when new event is
detected by advance_transaction() and acpi_ec_submit_event() is
called by it.
Next, the state can change from "In progress" directly to "Ready" in
the following situations:
* ec_event_clearing is ACPI_EC_EVT_TIMING_STATUS and the state of
an ACPI_EC_COMMAND_QUERY transaction becomes ACPI_EC_COMMAND_POLL.
* ec_event_clearing is ACPI_EC_EVT_TIMING_QUERY and the state of
an ACPI_EC_COMMAND_QUERY transaction becomes
ACPI_EC_COMMAND_COMPLETE.
* ec_event_clearing is either ACPI_EC_EVT_TIMING_STATUS or
ACPI_EC_EVT_TIMING_QUERY and there are no more events to
process (ie. ec->events_to_process becomes 0).
If ec_event_clearing is ACPI_EC_EVT_TIMING_EVENT, however, the
state must change from "In progress" to "Complete" before it
can change to "Ready". The changes from "In progress" to
"Complete" in that case occur in the following situations:
* The state of an ACPI_EC_COMMAND_QUERY transaction becomes
ACPI_EC_COMMAND_COMPLETE.
* There are no more events to process (ie. ec->events_to_process
becomes 0).
Finally, the state changes from "Complete" to "Ready" when
advance_transaction() is invoked when the state is "Complete" and
the state of the current transaction is not ACPI_EC_COMMAND_POLL.
To make this state machine visible in the code, add a new
event_state field to struct acpi_ec and modify the code to use
it istead the EC_FLAGS_QUERY_PENDING and EC_FLAGS_QUERY_GUARDING
flags.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Notice that it is not necessary to queue up the event work again
if the while () loop in acpi_ec_event_handler() is still running
which is the case if nr_pending_queries is greater than 0 at the
beginning of acpi_ec_submit_event() and modify the code to avoid
doing that.
While at it, rename nr_pending_queries in struct acpi_ec to
events_to_process which actually matches the role of that field
and change its data type to unsigned int which is sufficient.
No expected functional impact.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Rename acpi_ec_submit_query() to acpi_ec_submit_event(),
acpi_ec_query() to acpi_ec_submit_query(), and
acpi_ec_complete_query() to acpi_ec_close_event() to make
the names reflect what the functions do.
No expected functional impact.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Because acpi_ec_event_handler() is a work function, it always
runs in process context with interrupts enabled, so it can use
spin_lock_irq() and spin_unlock_irq() for the locking.
Make it do so and adjust white space around those calls.
No expected functional impact.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
It is not necessary to check ec->nr_pending_queries against 0 in the
while () loop in acpi_ec_event_handler(), because that loop terminates
when ec->nr_pending_queries is 0 and the code depending on that can be
run after the loop has ended.
Modify the code accordingly and while at it rewrite the comment
regarding that code to make it clearer.
No intentional functional impact.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Because acpi_ec_event_handler() is the only caller of
acpi_ec_check_event() and the separation of these two functions
makes it harder to follow the code flow, fold the latter into the
former (and simplify that code while at it).
No expected functional impact.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Notice that the second argument to acpi_ec_query() is redundant,
because in the only case when it is not NULL, the value passed
through it is only checked against 0 and it can only be 0 when
acpi_ec_query() returns an error code, but its return value
is checked along with the value passed through its second
argument.
Accordingly, modify acpi_ec_query() to take only one argument
and while at it, change its handling of the case when
acpi_ec_transaction() returns an error so as to return that
error value to the caller right away.
No expected functional impact.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Calling acpi_dispatch_gpe() from acpi_ec_dispatch_gpe() is generally
problematic, because it may cause the spurious interrupt handling in
advance_transaction() to trigger in theory.
However, instead of calling acpi_dispatch_gpe() to dispatch the EC
GPE, acpi_ec_dispatch_gpe() can call advance_transaction() directly
on first_ec and it can pass 'false' as its second argument to indicate
calling it from process context.
Moreover, if advance_transaction() is modified to return a bool value
indicating whether or not the EC work needs to be flushed, it can be
used to avoid unnecessary EC work flushing in acpi_ec_dispatch_gpe(),
so change the code accordingly.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
The flushing of pending work in the EC driver uses drain_workqueue()
to flush the event handling work that can requeue itself via
advance_transaction(), but this is problematic, because that
work may also be requeued from the query workqueue.
Namely, if an EC transaction is carried out during the execution of
a query handler, it involves calling advance_transaction() which
may queue up the event handling work again. This causes the kernel
to complain about attempts to add a work item to the EC event
workqueue while it is being drained and worst-case it may cause a
valid event to be skipped.
To avoid this problem, introduce two new counters, events_in_progress
and queries_in_progress, incremented when a work item is queued on
the event workqueue or the query workqueue, respectively, and
decremented at the end of the corresponding work function, and make
acpi_ec_dispatch_gpe() the workqueues in a loop until the both of
these counters are zero (or system wakeup is pending) instead of
calling acpi_ec_flush_work().
At the same time, change __acpi_ec_flush_work() to call
flush_workqueue() instead of drain_workqueue() to flush the event
workqueue.
While at it, use the observation that the work item queued in
acpi_ec_query() cannot be pending at that time, because it is used
only once, to simplify the code in there.
Additionally, clean up a comment in acpi_ec_query() and adjust white
space in acpi_ec_event_processor().
Fixes: f0ac20c3f613 ("ACPI: EC: Fix flushing of pending work")
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
The Xiaomi Mi Pad 2 has backlit LEDs behind the capacitive menu, home
and back buttons below the screen which are controlled by the PWM2
controller of the CHT SoC. This PWM2 controller gets hidden by the
firmware, add it to the always_present_ids table so that we can use
the PWM controller to control the backlighting of the buttons.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
The GPD win and its sibling the GPD pocket (99% the same electronics in a
different case) use a PCI wifi card. But the ACPI tables on both variants
contain a bug where the SDIO MMC controller for SDIO wifi cards is enabled
despite this. This SDIO MMC controller has a PCI0.SDHB.BRC1 child-device
which _PS3 method sets a GPIO causing the PCI wifi card to turn off.
At the moment there is a pretty ugly kludge in the sdhci-acpi.c code,
just to work around the bug in the DSDT of this single design. This can
be solved cleaner/simply with a quirk overriding the _STA return of the
broken PCI0.SDHB.BRC1 PCI0.SDHB.BRC1 child with a status value of 0,
so that its power_manageable flag gets cleared, avoiding this problem.
Note that even though it is not used, the _STA method for the MMC
controller is deliberately not overridden. If the status of the MMC
controller were forced to 0 it would never get suspended, which would
cause these mini-laptops to not reach S0i3 level when suspended.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Not all ACPI-devices have a HID + UID, allow specifying quirks for
acpi_device_override_status() by path too.
Note this moves the path/HID+UID check to after the CPU + DMI checks
since the path lookup is somewhat costly.
This way this lookup is only done on devices where the other checks
match.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Currently, acpi_bus_get_status() calls acpi_device_always_present() to
allow platform quirks to override the _STA return to report that a
device is present (status = ACPI_STA_DEFAULT) independent of the _STA
return.
In some cases it might also be useful to have the opposite functionality
and have a platform quirk which marks a device as not present (status = 0)
to work around ACPI table bugs.
Change acpi_device_always_present() into a more generic
acpi_device_override_status() function to allow this.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
It turns out that there is a WMI object which controls the PWM2 device
used for the keyboard backlight and that WMI object also provides some
other useful functionality.
The upcoming lenovo-yogabook-wmi driver will offer both backlight
control and the other functionality, so there no longer is a need
to have the lpss-pwm driver binding to PWM2 for backlight control;
and this is now actually undesirable because this will cause both
the WMI code and the lpss-pwm driver to poke at the same PWM
controller.
Drop the always-present quirk for the PWM2 ACPI-device, so that the
lpss-pwm controller will no longer bind to it.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Merge fix and cleanup related to the management of ACPI device
properties for 5.16-rc3.
* acpi-properties:
ACPI: Make acpi_node_get_parent() local
ACPI: Get acpi_device's parent from the parent field
Section 6.1.2 of ACPI 6.4 explicitly requires _HID to be present for
_CID to be defined, so don't add device IDs from _CID to the device
IDs list of a device if _HID is not valid.
Link: https://uefi.org/specs/ACPI/6.4/06_Device_Configuration/Device_Configuration.html#cid-compatible-id
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Address the following coccicheck warning:
./drivers/net/ethernet/mellanox/mlx5/core/en/tc_ct.c:914:40-41:
WARNING opportunity for swap().
by using swap() for the swapping of variable values and drop
the tmp variable that is not needed any more.
Signed-off-by: Guo Zhengkui <guozhengkui@vivo.com>
[ rjw: Subject and changelog rewrite ]
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
There is a comment in dptf_pch_fivr.c which seemingly was added under
the assumption that the PCH FIVR driver would be used on Tiger Lake
platforms, but support for Alder Lake has been udded to it by commit
38748bcb940e ("ACPI: DPTF: Support Alder Lake"), so update the
comment to cover a broader range of platforms by changing the device
ID mentioned by it to INTC10xx.
Signed-off-by: Sumeet Pawnikar <sumeet.r.pawnikar@intel.com>
[ rjw: Subject and changelog rewrite ]
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Print additional debug messages when enabling and disabling wakeup
power for an ACPI device object to facilitate more fine-grained
debugging of problems in that area.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Check cpc_desc against NULL in cppc_get_perf(), so it doesn't crash
down the road if cpc_desc is NULL.
Fixes: 0654cf05d17b ("ACPI: CPPC: Introduce cppc_get_nominal_perf()")
Reported-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Cc: 5.15+ <stable@vger.kernel.org> # 5.15+
Tested-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
acpi_node_get_parent() isn't used outside drivers/acpi/property.c.
Make it local.
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
