Re: [PATCH] ACPI: Add memory semantics to acpi_os_map_memory()
From: Ard Biesheuvel <ardb@kernel.org>
Date: 2021-07-27 10:10:02
Also in:
linux-acpi, lkml
On Tue, 27 Jul 2021 at 12:06, Lorenzo Pieralisi [off-list ref] wrote:
On Mon, Jul 26, 2021 at 05:55:33PM +0200, Ard Biesheuvel wrote:quoted
On Mon, 26 Jul 2021 at 12:00, Lorenzo Pieralisi [off-list ref] wrote:quoted
The memory attributes attached to memory regions depend on architecture specific mappings. For some memory regions, the attributes specified by firmware (eg uncached) are not sufficient to determine how a memory region should be mapped by an OS (for instance a region that is define as uncached in firmware can be mapped as Normal or Device memory on arm64) and therefore the OS must be given control on how to map the region to match the expected mapping behaviour (eg if a mapping is requested with memory semantics, it must allow unaligned accesses). Rework acpi_os_map_memory() and acpi_os_ioremap() back-end to split them into two separate code paths: acpi_os_memmap() -> memory semantics acpi_os_ioremap() -> MMIO semantics The split allows the architectural implementation back-ends to detect the default memory attributes required by the mapping in question (ie the mapping API defines the semantics memory vs MMIO) and map the memory accordingly. Link: https://lore.kernel.org/linux-arm-kernel/31ffe8fc-f5ee-2858-26c5-0fd8bdd68702@arm.com (local) Signed-off-by: Lorenzo Pieralisi <redacted> Cc: Ard Biesheuvel <ardb@kernel.org> Cc: Will Deacon <will@kernel.org> Cc: Hanjun Guo <guohanjun@huawei.com> Cc: Sudeep Holla <redacted> Cc: Catalin Marinas <catalin.marinas@arm.com> Cc: "Rafael J. Wysocki" <redacted>For the patch in general Acked-by: Ard Biesheuvel <ardb@kernel.org>Thanks ! [...]quoted
quoted
-void __iomem __ref -*acpi_os_map_iomem(acpi_physical_address phys, acpi_size size) +static void __iomem __ref +*__acpi_os_map_iomem(acpi_physical_address phys, acpi_size size, bool memory) { struct acpi_ioremap *map; void __iomem *virt;@@ -353,7 +356,7 @@ void __iomem __ref pg_off = round_down(phys, PAGE_SIZE); pg_sz = round_up(phys + size, PAGE_SIZE) - pg_off; - virt = acpi_map(phys, size); + virt = acpi_map(phys, size, memory); if (!virt) { mutex_unlock(&acpi_ioremap_lock); kfree(map);@@ -372,11 +375,17 @@ void __iomem __ref mutex_unlock(&acpi_ioremap_lock); return map->virt + (phys - map->phys); } + +void __iomem __ref +*acpi_os_map_iomem(acpi_physical_address phys, acpi_size size)I am aware that this just duplicated the prototype above, but I think this should be void __iomem *__ref given that the __ref comes after the * in the prototype below.Yes I just moved/duplicated the prototype above but I believe this is consistent with include/acpi/acpi_io.h unless I have not understood what you meant ? It is probably worth changing it in both places to void __iomem *__ref ? I can do that with an additional patch.
Yes, as long as they are all mutually consistent. The __ref is not part of the type at all, so it should not be between the void and the *, even if the compiler appears to allow it.
quoted
quoted
+{ + return __acpi_os_map_iomem(phys, size, false); +} EXPORT_SYMBOL_GPL(acpi_os_map_iomem); void *__ref acpi_os_map_memory(acpi_physical_address phys, acpi_size size) { - return (void *)acpi_os_map_iomem(phys, size); + return (void *)__acpi_os_map_iomem(phys, size, true);I think this should be (__force void *) to shut up sparse address space warnings.Yes I can add that attribute in an additional patch and rebase this one on top of it. Thanks, Lorenzoquoted
quoted
} EXPORT_SYMBOL_GPL(acpi_os_map_memory);diff --git a/include/acpi/acpi_io.h b/include/acpi/acpi_io.h index 027faa8883aa..a0212e67d6f4 100644 --- a/include/acpi/acpi_io.h +++ b/include/acpi/acpi_io.h@@ -14,6 +14,14 @@ static inline void __iomem *acpi_os_ioremap(acpi_physical_address phys, } #endif +#ifndef acpi_os_memmap +static inline void __iomem *acpi_os_memmap(acpi_physical_address phys, + acpi_size size) +{ + return ioremap_cache(phys, size); +} +#endif + extern bool acpi_permanent_mmap; void __iomem __ref --2.31.0
_______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel