Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
MIME-Version: 1.0
References: <20230526121751.41060-1-lihuisong@huawei.com> <CAMj1kXHgPbzgPm1Sq5hqqz7RX6sj2axze5F+fvMyfPY=d9=Hhw@mail.gmail.com>
 <d180192a-afad-00dc-426f-3d8d249cdd89@huawei.com>
In-Reply-To: <d180192a-afad-00dc-426f-3d8d249cdd89@huawei.com>
From:   Ard Biesheuvel <ardb@kernel.org>
Date:   Mon, 29 May 2023 15:31:12 +0200
Message-ID: <CAMj1kXHk-HTmJzovMFiYStZeZiehS2n01rhGeyOYF_wCn0sHbg@mail.gmail.com>
Subject: Re: [PATCH] arm64: acpi: Export symbol for acpi_os_ioremap
To:     "lihuisong (C)" <lihuisong@huawei.com>
Cc:     Lorenzo Pieralisi <lorenzo.pieralisi@linaro.org>,
        catalin.marinas@arm.com, will@kernel.org, sudeep.holla@arm.com,
        rafael.j.wysocki@intel.com, linux-arm-kernel@lists.infradead.org,
        linux-kernel@vger.kernel.org, anshuman.khandual@arm.com,
        wangkefeng.wang@huawei.com, liuyonglong@huawei.com
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Precedence: bulk

On Fri, 26 May 2023 at 15:12, lihuisong (C) <lihuisong@huawei.com> wrote:
>
>
> =E5=9C=A8 2023/5/26 20:39, Ard Biesheuvel =E5=86=99=E9=81=93:
> > (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] undef=
ined!
> >> scripts/Makefile.modpost:136: recipe for target 'Module.symvers' faile=
d
> >> 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_addres=
s 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 notificatio=
n.
> >> --
> >> 2.33.0
> >>
> >>
> >> _______________________________________________
> >> linux-arm-kernel mailing list
> >> linux-arm-kernel@lists.infradead.org
> >> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
> > .