On Fri, Jun 7, 2024 at 10:33 PM Pierre-Louis Bossart pierre-louis.bossart@linux.intel.com wrote:
On 6/7/24 20:51, Rafael J. Wysocki wrote:
On Tue, May 28, 2024 at 9:29 PM Pierre-Louis Bossart pierre-louis.bossart@linux.intel.com wrote:
The ACPI _ADR is a 64-bit value. We changed the definitions in commit ca6f998cf9a2 ("ACPI: bus: change _ADR representation to 64 bits") but some helpers still assume the value is a 32-bit value.
This patch adds a new helper to extract the full 64-bits. The existing 32-bit helper is kept for backwards-compatibility and cases where the _ADR is known to fit in a 32-bit value.
Signed-off-by: Pierre-Louis Bossart pierre-louis.bossart@linux.intel.com Reviewed-by: Péter Ujfalusi peter.ujfalusi@linux.intel.com Reviewed-by: Bard Liao yung-chuan.liao@linux.intel.com
Do you want me to apply this or do you want me to route it along with the rest of the series?
In the latter case feel free to add
Acked-by: Rafael J. Wysocki rafael.j.wysocki@intel.com
Thanks Rafael. I think it's easier if Mark Brown takes the series in ASoC, I have additional ASoC patches that use the u64 helper.
Mark?
+int acpi_get_local_u64_address(acpi_handle handle, u64 *addr) +{
acpi_status status;status = acpi_evaluate_integer(handle, METHOD_NAME__ADR, NULL, addr);if (ACPI_FAILURE(status))return -ENODATA;return 0;+} +EXPORT_SYMBOL(acpi_get_local_u64_address);
I'd prefer EXPORT_SYMBOL_GPL() here unless you absolutely cannot live with it.
I don't mind, but the existing helper was using EXPORT_SYMBOL so I just copied. It'd be odd to have two helpers that only differ by the argument size use a different EXPORT_ macro, no? Not to mention that the get_local address uses EXPORT_SYMBOL but would become a wrapper for an EXPORT_SYMBOL_GPL. That gives me a headache...
OK, fair enough.