Re: [PATCH v2 1/3] ACPI: osl: Add __force attribute in acpi_os_map_iomem() cast

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 2021-08-16 11:21, Ard Biesheuvel wrote:
On Mon, 16 Aug 2021 at 11:59, Lorenzo Pieralisi
<lorenzo.pieralisi@xxxxxxx> wrote:

On Wed, Aug 11, 2021 at 03:55:08PM +0100, Lorenzo Pieralisi wrote:
On Wed, Aug 11, 2021 at 03:08:24PM +0100, Christoph Hellwig wrote:
On Wed, Aug 11, 2021 at 12:40:28PM +0200, Ard Biesheuvel wrote:
The whole problem we are solving here is that ACPI, being based on
x86, conflates MMIO mappings with memory mappings, and has been using
the same underlying infrastructure for either.

So let's fix that problem instead of papering over it.

Patch (3) in this series is a fix - I would ask whether it makes
sense to merge patches (2-3) now and think about reworking the current
ACPI IO/MEM mapping API later, it can be an invasive change for a fix,
assuming we agree on how to rework the ACPI IO/MEM mapping API.

What should we do then with this series ?


It is not even clear that reworking the ACPI core is feasible to begin
with, OTOH, fixing a sparse warning is arguably not a critical bug fix
either, so I'd suggest we just drop that bit.

Indeed, the only way to truly fix the issue is to fire up the time machine and rewrite the ACPI and EFI specs to not define that tables and data may or may not be required to be mapped as Device memory depending on the whims of the firmware. Otherwise we're basically always going to have one or more casts *somewhere*, even if we were to play it safe and return everything as iomem instead.

I guess for read-only access to tables, the core code might be able to maintain a shadow copy of anything device-memory-mapped in normal memory and expose that instead, but if anything has to be writeable I'm not sure how we could abstract that "properly".

Robin.



[Index of Archives]     [Linux IBM ACPI]     [Linux Power Management]     [Linux Kernel]     [Linux Laptop]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Samba]     [Video 4 Linux]     [Device Mapper]     [Linux Resources]

  Powered by Linux