| Message ID | 20230526121751.41060-1-lihuisong@huawei.com (mailing list archive) |
|---|---|
| State | Not Applicable |
| Headers | show |
| Series | arm64: acpi: Export symbol for acpi_os_ioremap | expand |
(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. Why does it need to use acpi_os_ioremap() instead of the ordinary memremap/ioremap routines? > Signed-off-by: Huisong Li <lihuisong@huawei.com> > --- > arch/arm64/kernel/acpi.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/arch/arm64/kernel/acpi.c b/arch/arm64/kernel/acpi.c > index dba8fcec7f33..ec0414caf3d1 100644 > --- a/arch/arm64/kernel/acpi.c > +++ b/arch/arm64/kernel/acpi.c > @@ -354,6 +354,7 @@ void __iomem *acpi_os_ioremap(acpi_physical_address phys, acpi_size size) > } > return ioremap_prot(phys, size, pgprot_val(prot)); > } > +EXPORT_SYMBOL(acpi_os_ioremap); > > /* > * Claim Synchronous External Aborts as a firmware first notification. > -- > 2.33.0 > > > _______________________________________________ > linux-arm-kernel mailing list > linux-arm-kernel@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
在 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. > >> Signed-off-by: Huisong Li <lihuisong@huawei.com> >> --- >> arch/arm64/kernel/acpi.c | 1 + >> 1 file changed, 1 insertion(+) >> >> diff --git a/arch/arm64/kernel/acpi.c b/arch/arm64/kernel/acpi.c >> index dba8fcec7f33..ec0414caf3d1 100644 >> --- a/arch/arm64/kernel/acpi.c >> +++ b/arch/arm64/kernel/acpi.c >> @@ -354,6 +354,7 @@ void __iomem *acpi_os_ioremap(acpi_physical_address phys, acpi_size size) >> } >> return ioremap_prot(phys, size, pgprot_val(prot)); >> } >> +EXPORT_SYMBOL(acpi_os_ioremap); >> >> /* >> * Claim Synchronous External Aborts as a firmware first notification. >> -- >> 2.33.0 >> >> >> _______________________________________________ >> linux-arm-kernel mailing list >> linux-arm-kernel@lists.infradead.org >> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel > .
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. 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. > > > >> Signed-off-by: Huisong Li <lihuisong@huawei.com> > >> --- > >> arch/arm64/kernel/acpi.c | 1 + > >> 1 file changed, 1 insertion(+) > >> > >> diff --git a/arch/arm64/kernel/acpi.c b/arch/arm64/kernel/acpi.c > >> index dba8fcec7f33..ec0414caf3d1 100644 > >> --- a/arch/arm64/kernel/acpi.c > >> +++ b/arch/arm64/kernel/acpi.c > >> @@ -354,6 +354,7 @@ void __iomem *acpi_os_ioremap(acpi_physical_address phys, acpi_size size) > >> } > >> return ioremap_prot(phys, size, pgprot_val(prot)); > >> } > >> +EXPORT_SYMBOL(acpi_os_ioremap); > >> > >> /* > >> * Claim Synchronous External Aborts as a firmware first notification. > >> -- > >> 2.33.0 > >> > >> > >> _______________________________________________ > >> linux-arm-kernel mailing list > >> linux-arm-kernel@lists.infradead.org > >> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel > > .
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.
在 2023/5/30 18:58, Sudeep Holla 写道: > 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. Thank you. will drop this patch. >
diff --git a/arch/arm64/kernel/acpi.c b/arch/arm64/kernel/acpi.c index dba8fcec7f33..ec0414caf3d1 100644 --- a/arch/arm64/kernel/acpi.c +++ b/arch/arm64/kernel/acpi.c @@ -354,6 +354,7 @@ void __iomem *acpi_os_ioremap(acpi_physical_address phys, acpi_size size) } return ioremap_prot(phys, size, pgprot_val(prot)); } +EXPORT_SYMBOL(acpi_os_ioremap); /* * Claim Synchronous External Aborts as a firmware first notification.
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. Signed-off-by: Huisong Li <lihuisong@huawei.com> --- arch/arm64/kernel/acpi.c | 1 + 1 file changed, 1 insertion(+)