Messages in this thread | | | Date | Tue, 30 May 2023 11:58:43 +0100 | From | Sudeep Holla <> | Subject | Re: [PATCH] arm64: acpi: Export symbol for acpi_os_ioremap |
| |
On Mon, May 29, 2023 at 03:31:12PM +0200, Ard Biesheuvel wrote: > On Fri, 26 May 2023 at 15:12, lihuisong (C) <lihuisong@huawei.com> wrote: > > > > > > 在 2023/5/26 20:39, Ard Biesheuvel 写道: > > > (cc Lorenzo) > > > > > > On Fri, 26 May 2023 at 14:20, Huisong Li <lihuisong@huawei.com> wrote: > > >> The driver who calls the acpi_os_ioremap() cannot be compiled if the 'M' > > >> is selected for the driver. The compiling log is as follows: > > >> --> > > >> MODPOST Module.symvers > > >> ERROR: modpost: "acpi_os_ioremap" [drivers/soc/hisilicon/xxx.ko] undefined! > > >> scripts/Makefile.modpost:136: recipe for target 'Module.symvers' failed > > >> make[1]: *** [Module.symvers] Error 1 > > >> > > >> So this patch exports symbol for acpi_os_ioremap. > > >> > > > That driver does not exist in mainline. > > > > We have an uploading driver [1] that may use it. > > > > [1] > > https://patchwork.kernel.org/project/linux-soc/patch/20230522072211.8894-2-lihuisong@huawei.com/ > > > > > > > > Why does it need to use acpi_os_ioremap() instead of the ordinary > > > memremap/ioremap routines? > > This driver needs to ioremap the shared memory space of a PCC subspace. > > And @Sudeep suggested that we use this interface. > > It is suitable here. > > I disagree. acpi_io_ioremap() is internal arch plumbing for the ACPI > subsystem. I don't see why we should use it here. >
Yes. One reason I suggested this was in past firmware authors had mixed the memory allocated for PCC and using acpi_io_ioremap() made sense. But I hear you and it make sense to avoid it especially if the driver must know what type of memory it is and must be dealing with.
> On arm64, acpi_os_ioremap() cross references the EFI memory map to > figure out whether a physical region is memory or device, but a driver > should already know that.
Agreed.
-- Regards, Sudeep
| |