On Sun, 25 Jun 2023 at 13:54, 运辉崔 <cuiyunhui@xxxxxxxxxxxxx> wrote:
>
> Hi Ard,
>
> On Sun, Jun 25, 2023 at 3:43 PM Ard Biesheuvel <ardb@xxxxxxxxxx> wrote:
> >
> > acpi_os_ioremap() is used by all ACPI core code that needs to map MMIO
> > regions or DRAM from AML code. AML does not pass memory type
> > attributes, so we have to consult the EFI memory map for these.
> >
> > As I have explained to you multiple times, ACPI on arm64 is *broken*
> > without the EFI memory map.
> >
>
> As Ron's suggested:
> "...
> It would be nice to separate those pieces on RISC-V; certainly they
> were separate for a very long time in the x86 world (we had ACPI+SMM
> on coreboot laptops without UEFI for example)
> ...
> "
>
> If it cannot be solved temporarily on arm64, then we cannot let it
> continue to be bound in RISC-V.
> And on the linux-next branch, RISC-V arch is not bound to EFI.
> void *acpi_os_ioremap(acpi_physical_address phys, acpi_size size)
> {
> return memremap(phys, size, MEMREMAP_WB);
> }
>
>
>
> >
> > Incorrect. We are talking about any physical region here, not just
> > DRAM. And some DRAM regions may not be covered by memblock.
> >
> It is very strange that so many devices can complete the hardware
> description through DTS without the problem you mentioned.
> Even if there is, then it shouldn't be the problem that this patch
> should solve, should it?
>
> > No, sorry. Please try to understand the objections that I am raising
> > first. I am not saying this to annoy you, I am saying this because
> > your approach is flawed.
>
> The implementation is right in front of us, we need to support ACPI on
> RISC-V based on coreboot.
>
If this is only used on RISC-V, and implemented under arch/riscv, I
have no objections.
