// SPDX-License-Identifier: GPL-2.0 /* * helpers to map values in a linear range to range index * * Original idea borrowed from regulator framework * * It might be useful if we could support also inversely proportional ranges? * Copyright 2020 ROHM Semiconductors */ #include #include #include #include #include /** * linear_range_values_in_range - return the amount of values in a range * @r: pointer to linear range where values are counted * * Compute the amount of values in range pointed by @r. Note, values can * be all equal - range with selectors 0,...,2 with step 0 still contains * 3 values even though they are all equal. * * Return: the amount of values in range pointed by @r */ unsigned int linear_range_values_in_range(const struct linear_range *r) { if (!r) return 0; return r->max_sel - r->min_sel + 1; } EXPORT_SYMBOL_GPL(linear_range_values_in_range); /** * linear_range_values_in_range_array - return the amount of values in ranges * @r: pointer to array of linear ranges where values are counted * @ranges: amount of ranges we include in computation. * * Compute the amount of values in ranges pointed by @r. Note, values can * be all equal - range with selectors 0,...,2 with step 0 still contains * 3 values even though they are all equal. * * Return: the amount of values in first @ranges ranges pointed by @r */ unsigned int linear_range_values_in_range_array(const struct linear_range *r, int ranges) { int i, values_in_range = 0; for (i = 0; i < ranges; i++) { int values; values = linear_range_values_in_range(&r[i]); if (!values) return values; values_in_range += values; } return values_in_range; } EXPORT_SYMBOL_GPL(linear_range_values_in_range_array); /** * linear_range_get_max_value - return the largest value in a range * @r: pointer to linear range where value is looked from * * Return: the largest value in the given range */ unsigned int linear_range_get_max_value(const struct linear_range *r) { return r->min + (r->max_sel - r->min_sel) * r->step; } EXPORT_SYMBOL_GPL(linear_range_get_max_value); /** * linear_range_get_value - fetch a value from given range * @r: pointer to linear range where value is looked from * @selector: selector for which the value is searched * @val: address where found value is updated * * Search given ranges for value which matches given selector. * * Return: 0 on success, -EINVAL given selector is not found from any of the * ranges. */ int linear_range_get_value(const struct linear_range *r, unsigned int selector, unsigned int *val) { if (r->min_sel > selector || r->max_sel < selector) return -EINVAL; *val = r->min + (selector - r->min_sel) * r->step; return 0; } EXPORT_SYMBOL_GPL(linear_range_get_value); /** * linear_range_get_value_array - fetch a value from array of ranges * @r: pointer to array of linear ranges where value is looked from * @ranges: amount of ranges in an array * @selector: selector for which the value is searched * @val: address where found value is updated * * Search through an array of ranges for value which matches given selector. * * Return: 0 on success, -EINVAL given selector is not found from any of the * ranges. */ int linear_range_get_value_array(const struct linear_range *r, int ranges, unsigned int selector, unsigned int *val) { int i; for (i = 0; i < ranges; i++) if (r[i].min_sel <= selector && r[i].max_sel >= selector) return linear_range_get_value(&r[i], selector, val); return -EINVAL; } EXPORT_SYMBOL_GPL(linear_range_get_value_array); /** * linear_range_get_selector_low - return linear range selector for value * @r: pointer to linear range where selector is looked from * @val: value for which the selector is searched * @selector: address where found selector value is updated * @found: flag to indicate that given value was in the range * * Return selector which which range value is closest match for given * input value. Value is matching if it is equal or smaller than given * value. If given value is in the range, then @found is set true. * * Return: 0 on success, -EINVAL if range is invalid or does not contain * value smaller or equal to given value */ int linear_range_get_selector_low(const struct linear_range *r, unsigned int val, unsigned int *selector, bool *found) { *found = false; if (r->min > val) return -EINVAL; if (linear_range_get_max_value(r) < val) { *selector = r->max_sel; return 0; } *found = true; if (r->step == 0) *selector = r->min_sel; else *selector = (val - r->min) / r->step + r->min_sel; return 0; } EXPORT_SYMBOL_GPL(linear_range_get_selector_low); /** * linear_range_get_selector_low_array - return linear range selector for value * @r: pointer to array of linear ranges where selector is looked from * @ranges: amount of ranges to scan from array * @val: value for which the selector is searched * @selector: address where found selector value is updated * @found: flag to indicate that given value was in the range * * Scan array of ranges for selector which which range value matches given * input value. Value is matching if it is equal or smaller than given * value. If given value is found to be in a range scanning is stopped and * @found is set true. If a range with values smaller than given value is found * but the range max is being smaller than given value, then the ranges * biggest selector is updated to @selector but scanning ranges is continued * and @found is set to false. * * Return: 0 on success, -EINVAL if range array is invalid or does not contain * range with a value smaller or equal to given value */ int linear_range_get_selector_low_array(const struct linear_range *r, int ranges, unsigned int val, unsigned int *selector, bool *found) { int i; int ret = -EINVAL; for (i = 0; i < ranges; i++) { int tmpret; tmpret = linear_range_get_selector_low(&r[i], val, selector, found); if (!tmpret) ret = 0; if (*found) break; } return ret; } EXPORT_SYMBOL_GPL(linear_range_get_selector_low_array); /** * linear_range_get_selector_high - return linear range selector for value * @r: pointer to linear range where selector is looked from * @val: value for which the selector is searched * @selector: address where found selector value is updated * @found: flag to indicate that given value was in the range * * Return selector which which range value is closest match for given * input value. Value is matching if it is equal or higher than given * value. If given value is in the range, then @found is set true. * * Return: 0 on success, -EINVAL if range is invalid or does not contain * value greater or equal to given value */ int linear_range_get_selector_high(const struct linear_range *r, unsigned int val, unsigned int *selector, bool *found) { *found = false; if (linear_range_get_max_value(r) < val) return -EINVAL; if (r->min > val) { *selector = r->min_sel; return 0; } *found = true; if (r->step == 0) *selector = r->max_sel; else *selector = DIV_ROUND_UP(val - r->min, r->step) + r->min_sel; return 0; } EXPORT_SYMBOL_GPL(linear_range_get_selector_high); MODULE_DESCRIPTION("linear-ranges helper"); MODULE_LICENSE("GPL"); -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/3236716.5fSG56mABF@rjwysocki.net 2024-06-13ACPI: EC: Evaluate orphan _REG under EC deviceRafael J. Wysocki After starting to install the EC address space handler at the ACPI namespace root, if there is an "orphan" _REG method in the EC device's scope, it will not be evaluated any more. This breaks EC operation regions on some systems, like Asus gu605. To address this, use a wrapper around an existing ACPICA function to look for an "orphan" _REG method in the EC device scope and evaluate it if present. Fixes: 60fa6ae6e6d0 ("ACPI: EC: Install address space handler at the namespace root") Closes: https://bugzilla.kernel.org/show_bug.cgi?id=218945 Reported-by: VitaliiT <vitaly.torshyn@gmail.com> Tested-by: VitaliiT <vitaly.torshyn@gmail.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> 2023-04-06ACPICA: Update all copyrights/signons to 2023Bob Moore ACPICA commit 25bddd1824b1e450829468a64bbdcb38074ba3d2 Copyright updates to 2023. Link: https://github.com/acpica/acpica/commit/25bddd18 Signed-off-by: Bob Moore <robert.moore@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> 2022-04-13ACPICA: Update copyright notices to the year 2022Bob Moore ACPICA commit 738d7b0726e6c0458ef93c0a01c0377490888d1e Affects all source modules and utility signons. Link: https://github.com/acpica/acpica/commit/738d7b07 Signed-off-by: Bob Moore <robert.moore@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> 2021-12-27ACPICA: Use original data_table_region pointer for accessesJessica Clarke 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> 2021-01-22ACPICA: Updated all copyrights to 2021Bob Moore This affects all ACPICA source code modules. ACPICA commit c570953c914437e621dd5f160f26ddf352e0d2f4 Link: https://github.com/acpica/acpica/commit/c570953c Signed-off-by: Bob Moore <robert.moore@intel.com> Signed-off-by: Erik Kaneda <erik.kaneda@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> 2020-01-13ACPICA: All acpica: Update copyrights to 2020 Including tool signons.Bob Moore ACPICA commit 8b9c69d0984067051ffbe8526f871448ead6a26b Link: https://github.com/acpica/acpica/commit/8b9c69d0 Signed-off-by: Bob Moore <robert.moore@intel.com> Signed-off-by: Erik Kaneda <erik.kaneda@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> 2019-06-19ACPICA: Clear status of GPEs on first direct enableRafael J. Wysocki ACPI GPEs (other than the EC one) can be enabled in two situations. First, the GPEs with existing _Lxx and _Exx methods are enabled implicitly by ACPICA during system initialization. Second, the GPEs without these methods (like GPEs listed by _PRW objects for wakeup devices) need to be enabled directly by the code that is going to use them (e.g. ACPI power management or device drivers). In the former case, if the status of a given GPE is set to start with, its handler method (either _Lxx or _Exx) needs to be invoked to take care of the events (possibly) signaled before the GPE was enabled. In the latter case, however, the first caller of acpi_enable_gpe() for a given GPE should not be expected to care about any events that might be signaled through it earlier. In that case, it is better to clear the status of the GPE before enabling it, to prevent stale events from triggering unwanted actions (like spurious system resume, for example). For this reason, modify acpi_ev_add_gpe_reference() to take an additional boolean argument indicating whether or not the GPE status needs to be cleared when its reference counter changes from zero to one and make acpi_enable_gpe() pass TRUE to it through that new argument. Fixes: 18996f2db918 ("ACPICA: Events: Stop unconditionally clearing ACPI IRQs during suspend/resume") Reported-by: Furquan Shaikh <furquan@google.com> Tested-by: Furquan Shaikh <furquan@google.com> Tested-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> 2019-01-15ACPICA: All acpica: Update copyrights to 2019Bob Moore ACPICA commit 62f4f98e941d86e41969bf2ab5a93b8dc94dc49e The update includes userspace tool signons. Link: https://github.com/acpica/acpica/commit/62f4f98e Signed-off-by: Bob Moore <robert.moore@intel.com> Signed-off-by: Erik Schmauss <erik.schmauss@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> 2018-10-04ACPICA: Never run _REG on system_memory and system_IOBob Moore These address spaces are defined by the ACPI spec to be "always available", and thus _REG should never be run on them. Provides compatibility with other ACPI implementations. Signed-off-by: Bob Moore <robert.moore@intel.com> Signed-off-by: Erik Schmauss <erik.schmauss@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> 2018-03-18ACPICA: adding SPDX headersErik Schmauss Signed-off-by: Erik Schmauss <erik.schmauss@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> 2018-03-18ACPICA: Events: Dispatch GPEs after enabling for the first timeErik Schmauss After being enabled for the first time, the GPEs may have STS bits already set. Setting EN bits is not sufficient to trigger the GPEs again, so this patch polls GPEs after enabling them for the first time. This is a cleaner version on top of the "GPE clear" fix generated according to Mika's report and Rafael's original Linux based fix. Based on Linux commit originated from Rafael J. Wysocki, fixed by Lv Zheng. Signed-off-by: Lv Zheng <lv.zheng@intel.com> Signed-off-by: Erik Schmauss <erik.schmauss@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> 2018-03-18ACPICA: Events: Add parallel GPE handling support to fix potential redundant ↵Erik Schmauss _Exx evaluations There is a risk that a GPE method/handler may be invoked twice. Let's consider a case, both GPE0(RAW_HANDLER) and GPE1(_Exx) is triggered. =======================================+============================= IRQ handler (top-half) |IRQ polling =======================================+============================= acpi_ev_detect_gpe() | LOCK() | READ (GPE0-7 enable/status registers)| ^^^^^^^^^^^^ROOT CAUSE^^^^^^^^^^^^^^^| Walk GPE0 | UNLOCK() |LOCK() Invoke GPE0 RAW_HANDLER |READ (GPE1 enable/status bit) |acpi_ev_gpe_dispatch(irq=false) | CLEAR (GPE1 enable bit) | CLEAR (GPE1 status bit) LOCK() |UNLOCK() Walk GPE1 +============================= acpi_ev_gpe_dispatch(irq=true) |IRQ polling (defer) CLEAR (GPE1 enable bit) +============================= CLEAR (GPE1 status bit) |acpi_ev_async_execute_gpe_method() Walk others | Evaluate GPE1 _Exx fi | acpi_ev_async_enable_gpe() UNLOCK() | LOCK() =======================================+ SET (GPE enable bit) IRQ handler (bottom-half) | UNLOCK() =======================================+ acpi_ev_async_execute_gpe_method() | Evaluate GPE1 _Exx | acpi_ev_async_enable_gpe() | LOCK() | SET (GPE1 enable bit) | UNLOCK() | =======================================+============================= If acpi_ev_detect_gpe() is only invoked from the IRQ context, there won't be more than one _Lxx/_Exx evaluations for one status bit flagging if the IRQ handlers controlled by the underlying IRQ chip/driver (ex. APIC) are run in serial. Note that, this is a known potential gap and we had an approach, locking entire non-raw-handler processes in the top-half IRQ handler and handling all raw-handlers out of the locked loop to be friendly to those IRQ chip/driver. But the approach is too complicated while the issue is not so real, thus ACPICA treated such issue (if any) as a parallelism/quality issue of the underlying IRQ chip/driver to stop putting it on the radar. Bug in link #1 is suspiciously reflecting the same cause, and if so, it can also be fixed by this simpler approach. But it will be no excuse an ACPICA problem now if ACPICA starts to poll IRQs itself. In the changed scenario, _Exx will be evaluated from the task context due to new ACPICA provided "polling after enabling GPEs" mechanism. And the above figure uses edge-triggered GPEs demonstrating the possibility of evaluating _Exx twice for one status bit flagging. As a conclusion, there is now an increased chance of evaluating _Lxx/_Exx more than once for one status bit flagging. However this is still not a real problem if the _Lxx/_Exx checks the underlying hardware IRQ reasoning and finally just changes the 2nd and the follow-up evaluations into no-ops. Note that _Lxx should always be written in this way as a level-trigger GPE could have it's status wrongly duplicated by the underlying IRQ delivery mechanisms. But _Exx may have very low quality BIOS by BIOS to trigger real issues. For example, trigger duplicated button notifications. To solve this issue, we need to stop reading a bunch of enable/status register bits, but read only one GPE's enable/status bit. And GPE status register's W1C nature ensures that acknowledging one GPE won't affect another GPEs' status bits. Thus the hardware GPE architecture has already provided us with the mechanism of implementing such parallelism. So we can lock around one GPE handling process to achieve the parallelism: 1. If we can incorporate GPE enable bit check in detection and ensure the atomicity of the following process (top-half IRQ handler): READ (enable/status bit) if (enabled && raised) CLEAR (enable bit) and handle the GPE after this process, we can ensure that we will only invoke GPE handler once for one status bit flagging. 2. In addtion for edge-triggered GPEs, if we can ensure the atomicity of the following process (top-half IRQ handler): READ (enable/status bit) if (enabled && raised) CLEAR (enable bit) CLEAR (status bit) and handle the GPE after this process, we can ensure that we will only invoke GPE handler once for one status bit flagging. By doing a cleanup in this way, we can remove duplicate GPE handling code and ensure that all logics are collected in 1 function. And the function will be safe for both IRQ interrupt and IRQ polling, and will be safe for us to release and re-acquire acpi_gbl_gpe_lock at any time rather than raw handler only during the top-half IRQ handler. Lv Zheng. Link: https://bugzilla.kernel.org/show_bug.cgi?id=196703 [#1] Signed-off-by: Lv Zheng <lv.zheng@intel.com> Signed-off-by: Erik Schmauss <erik.schmauss@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> 2018-02-06ACPICA: All acpica: Update copyrights to 2018Bob Moore including tool signons. Signed-off-by: Bob Moore <robert.moore@intel.com> Signed-off-by: Erik Schmauss <erik.schmauss@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> 2017-02-09ACPICA: Source tree: Update copyright notices to 2017Bob Moore ACPICA commit 16577e5265923f4999b4d2c0addb2343b18135e1 Affects all files. Link: https://github.com/acpica/acpica/commit/16577e52 Signed-off-by: Bob Moore <robert.moore@intel.com> Signed-off-by: Lv Zheng <lv.zheng@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> 2016-12-01ACPICA: Events: Fix acpi_ev_initialize_region() return valueLv Zheng ACPICA commit 543342ab7a676f4eb0c9f100d349388a84dff0e8 This patch changes acpi_ev_initialize_region(), stop returning AE_NOT_EXIST from it so that, not only in acpi_ds_load2_end_op(), but all places invoking this function won't emit exceptions. The exception can be seen in acpi_ds_initialize_objects() when certain table loading mode is chosen. This patch also removes useless acpi_ns_locked from acpi_ev_initialize_region() as this function will always be invoked with interpreter lock held now, and the lock granularity has been tuned to lock around _REG execution, thus it is now handled by acpi_ex_exit_interpreter(). Lv Zheng. Link: https://github.com/acpica/acpica/commit/543342ab Signed-off-by: Lv Zheng <lv.zheng@intel.com> Signed-off-by: Bob Moore <robert.moore@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> 2016-08-13ACPICA: Events: Introduce acpi_mask_gpe() to implement GPE masking mechanismLv Zheng ACPICA commit 23a417ca406a527e7ae1710893e59a8b6db30e14 There is a facility in Linux, developers can control the enabling/disabling of a GPE via /sys/firmware/acpi/interrupts/gpexx. This is mainly for debugging purposes. But many users expect to use this facility to implement quirks to mask a specific GPE when there is a gap in Linux causing this GPE to flood. This is not working correctly because currently this facility invokes enabling/disabling counting based GPE driver APIs: acpi_enable_gpe()/acpi_disable_gpe() and the GPE drivers can still affect the count to mess up the GPE masking purposes. However, most of the IRQ chip designs allow masking/unmasking IRQs via a masking bit which is different from the enabled bit to achieve the same purpose. But the GPE hardware doesn't contain such a feature, this brings the trouble. In this patch, we introduce a software mechanism to implement the GPE masking feature, and acpi_mask_gpe() are provided to the OSPMs to mask/unmask GPEs in the above mentioned situation instead of acpi_enable_gpe()/acpi_disable_gpe(). ACPICA BZ 1102. Lv Zheng. Link: https://github.com/acpica/acpica/commit/23a417ca Link: https://bugs.acpica.org/show_bug.cgi?id=1102 Signed-off-by: Lv Zheng <lv.zheng@intel.com> Signed-off-by: Bob Moore <robert.moore@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> 2016-05-05ACPICA: Divergence: remove unwanted spaces for typedefLv Zheng ACPICA commit b2294cae776f5a66a7697414b21949d307e6856f This patch removes unwanted spaces for typedef. This solution doesn't cover function types. Note that the linuxize result of this commit is very giant and should have many conflicts against the current Linux upstream. Thus it is required to modify the linuxize result of this commit and the commits around it manually in order to have them merged to the Linux upstream. Since this is very costy, we should do this only once, and if we can't ensure to do this only once, we need to revert the Linux code to the wrong indentation result before merging the linuxize result of this commit. Lv Zheng. Link: https://github.com/acpica/acpica/commit/b2294cae Signed-off-by: Lv Zheng <lv.zheng@intel.com> Signed-off-by: Bob Moore <robert.moore@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>