[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CAMj1kXHgaLD43jx0f6hn_j209LGT_4G+w5XEGaYB9znV5p9tdA@mail.gmail.com>
Date: Sun, 25 Jun 2023 15:12:54 +0200
From: Ard Biesheuvel <ardb@...nel.org>
To: 运辉崔 <cuiyunhui@...edance.com>
Cc: ron minnich <rminnich@...il.com>,
Mark Rutland <mark.rutland@....com>,
Lorenzo Pieralisi <lpieralisi@...nel.org>, rafael@...nel.org,
lenb@...nel.org, jdelvare@...e.com, yc.hung@...iatek.com,
angelogioacchino.delregno@...labora.com,
allen-kh.cheng@...iatek.com, pierre-louis.bossart@...ux.intel.com,
tinghan.shen@...iatek.com, linux-kernel@...r.kernel.org,
linux-acpi@...r.kernel.org, geshijian@...edance.com,
weidong.wd@...edance.com
Subject: Re: [External] Re: [PATCH] firmware: added a firmware information
passing method FFI
On Sun, 25 Jun 2023 at 13:54, 运辉崔 <cuiyunhui@...edance.com> wrote:
>
> Hi Ard,
>
> On Sun, Jun 25, 2023 at 3:43 PM Ard Biesheuvel <ardb@...nel.org> 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.
Powered by blists - more mailing lists