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 <[email protected]>
---
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
(cc Lorenzo)
On Fri, 26 May 2023 at 14:20, Huisong Li <[email protected]> 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 <[email protected]>
> ---
> 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
> [email protected]
> 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 <[email protected]> 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/[email protected]/
>
> 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 <[email protected]>
>> ---
>> 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
>> [email protected]
>> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
> .
On Fri, 26 May 2023 at 15:12, lihuisong (C) <[email protected]> wrote:
>
>
> 在 2023/5/26 20:39, Ard Biesheuvel 写道:
> > (cc Lorenzo)
> >
> > On Fri, 26 May 2023 at 14:20, Huisong Li <[email protected]> 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/[email protected]/
>
> >
> > 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 <[email protected]>
> >> ---
> >> 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
> >> [email protected]
> >> 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) <[email protected]> wrote:
> >
> >
> > 在 2023/5/26 20:39, Ard Biesheuvel 写道:
> > > (cc Lorenzo)
> > >
> > > On Fri, 26 May 2023 at 14:20, Huisong Li <[email protected]> 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/[email protected]/
> >
> > >
> > > 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
在 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) <[email protected]> wrote:
>>>
>>> 在 2023/5/26 20:39, Ard Biesheuvel 写道:
>>>> (cc Lorenzo)
>>>>
>>>> On Fri, 26 May 2023 at 14:20, Huisong Li <[email protected]> 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/[email protected]/
>>>
>>>> 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.
>