All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ard Biesheuvel <ardb@kernel.org>
To: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Will Deacon <will@kernel.org>, Hanjun Guo <guohanjun@huawei.com>,
	Sudeep Holla <sudeep.holla@arm.com>,
	Catalin Marinas <catalin.marinas@arm.com>,
	"Rafael J. Wysocki" <rjw@rjwysocki.net>,
	ACPI Devel Maling List <linux-acpi@vger.kernel.org>,
	Linux ARM <linux-arm-kernel@lists.infradead.org>,
	Veronika kabatova <vkabatov@redhat.com>,
	Robin Murphy <robin.murphy@arm.com>
Subject: Re: [PATCH] ACPI: Add memory semantics to acpi_os_map_memory()
Date: Tue, 27 Jul 2021 12:09:47 +0200	[thread overview]
Message-ID: <CAMj1kXHwPXX9MxuF_cw1bq9v+qzH-M4-_ssES8WQq-YP3APthg@mail.gmail.com> (raw)
In-Reply-To: <20210727100645.GA7108@lpieralisi>

On Tue, 27 Jul 2021 at 12:06, Lorenzo Pieralisi
<lorenzo.pieralisi@arm.com> wrote:
>
> On Mon, Jul 26, 2021 at 05:55:33PM +0200, Ard Biesheuvel wrote:
> > On Mon, 26 Jul 2021 at 12:00, Lorenzo Pieralisi
> > <lorenzo.pieralisi@arm.com> wrote:
> > >
> > > The memory attributes attached to memory regions depend on architecture
> > > specific mappings.
> > >
> > > For some memory regions, the attributes specified by firmware (eg
> > > uncached) are not sufficient to determine how a memory region should be
> > > mapped by an OS (for instance a region that is define as uncached in
> > > firmware can be mapped as Normal or Device memory on arm64) and
> > > therefore the OS must be given control on how to map the region to match
> > > the expected mapping behaviour (eg if a mapping is requested with memory
> > > semantics, it must allow unaligned accesses).
> > >
> > > Rework acpi_os_map_memory() and acpi_os_ioremap() back-end to split
> > > them into two separate code paths:
> > >
> > > acpi_os_memmap() -> memory semantics
> > > acpi_os_ioremap() -> MMIO semantics
> > >
> > > The split allows the architectural implementation back-ends to detect
> > > the default memory attributes required by the mapping in question
> > > (ie the mapping API defines the semantics memory vs MMIO) and map the
> > > memory accordingly.
> > >
> > > Link: https://lore.kernel.org/linux-arm-kernel/31ffe8fc-f5ee-2858-26c5-0fd8bdd68702@arm.com
> > > Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
> > > Cc: Ard Biesheuvel <ardb@kernel.org>
> > > Cc: Will Deacon <will@kernel.org>
> > > Cc: Hanjun Guo <guohanjun@huawei.com>
> > > Cc: Sudeep Holla <sudeep.holla@arm.com>
> > > Cc: Catalin Marinas <catalin.marinas@arm.com>
> > > Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>
> >
> > For the patch in general
> >
> > Acked-by: Ard Biesheuvel <ardb@kernel.org>
>
> Thanks !
>
> [...]
>
> > > -void __iomem __ref
> > > -*acpi_os_map_iomem(acpi_physical_address phys, acpi_size size)
> > > +static void __iomem __ref
> > > +*__acpi_os_map_iomem(acpi_physical_address phys, acpi_size size, bool memory)
> > >  {
> > >         struct acpi_ioremap *map;
> > >         void __iomem *virt;
> > > @@ -353,7 +356,7 @@ void __iomem __ref
> > >
> > >         pg_off = round_down(phys, PAGE_SIZE);
> > >         pg_sz = round_up(phys + size, PAGE_SIZE) - pg_off;
> > > -       virt = acpi_map(phys, size);
> > > +       virt = acpi_map(phys, size, memory);
> > >         if (!virt) {
> > >                 mutex_unlock(&acpi_ioremap_lock);
> > >                 kfree(map);
> > > @@ -372,11 +375,17 @@ void __iomem __ref
> > >         mutex_unlock(&acpi_ioremap_lock);
> > >         return map->virt + (phys - map->phys);
> > >  }
> > > +
> > > +void __iomem __ref
> > > +*acpi_os_map_iomem(acpi_physical_address phys, acpi_size size)
> >
> > I am aware that this just duplicated the prototype above, but I think
> > this should be
> >
> > void __iomem *__ref
> >
> > given that the __ref comes after the * in the prototype below.
>
> Yes I just moved/duplicated the prototype above but I believe this is
> consistent with include/acpi/acpi_io.h unless I have not understood
> what you meant ?
>
> It is probably worth changing it in both places to
>
> void __iomem *__ref
>
> ?
>
> I can do that with an additional patch.
>

Yes, as long as they are all mutually consistent. The __ref is not
part of the type at all, so it should not be between the void and the
*, even if the compiler appears to allow it.


> >
> > > +{
> > > +       return __acpi_os_map_iomem(phys, size, false);
> > > +}
> > >  EXPORT_SYMBOL_GPL(acpi_os_map_iomem);
> > >
> > >  void *__ref acpi_os_map_memory(acpi_physical_address phys, acpi_size size)
> > >  {
> > > -       return (void *)acpi_os_map_iomem(phys, size);
> > > +       return (void *)__acpi_os_map_iomem(phys, size, true);
> >
> > I think this should be (__force void *) to shut up sparse address
> > space warnings.
>
> Yes I can add that attribute in an additional patch and rebase this one
> on top of it.
>
> Thanks,
> Lorenzo
>
> >
> > >  }
> > >  EXPORT_SYMBOL_GPL(acpi_os_map_memory);
> > >
> > > diff --git a/include/acpi/acpi_io.h b/include/acpi/acpi_io.h
> > > index 027faa8883aa..a0212e67d6f4 100644
> > > --- a/include/acpi/acpi_io.h
> > > +++ b/include/acpi/acpi_io.h
> > > @@ -14,6 +14,14 @@ static inline void __iomem *acpi_os_ioremap(acpi_physical_address phys,
> > >  }
> > >  #endif
> > >
> > > +#ifndef acpi_os_memmap
> > > +static inline void __iomem *acpi_os_memmap(acpi_physical_address phys,
> > > +                                           acpi_size size)
> > > +{
> > > +       return ioremap_cache(phys, size);
> > > +}
> > > +#endif
> > > +
> > >  extern bool acpi_permanent_mmap;
> > >
> > >  void __iomem __ref
> > > --
> > > 2.31.0
> > >

WARNING: multiple messages have this Message-ID (diff)
From: Ard Biesheuvel <ardb@kernel.org>
To: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Will Deacon <will@kernel.org>,  Hanjun Guo <guohanjun@huawei.com>,
	Sudeep Holla <sudeep.holla@arm.com>,
	 Catalin Marinas <catalin.marinas@arm.com>,
	"Rafael J. Wysocki" <rjw@rjwysocki.net>,
	 ACPI Devel Maling List <linux-acpi@vger.kernel.org>,
	 Linux ARM <linux-arm-kernel@lists.infradead.org>,
	 Veronika kabatova <vkabatov@redhat.com>,
	Robin Murphy <robin.murphy@arm.com>
Subject: Re: [PATCH] ACPI: Add memory semantics to acpi_os_map_memory()
Date: Tue, 27 Jul 2021 12:09:47 +0200	[thread overview]
Message-ID: <CAMj1kXHwPXX9MxuF_cw1bq9v+qzH-M4-_ssES8WQq-YP3APthg@mail.gmail.com> (raw)
In-Reply-To: <20210727100645.GA7108@lpieralisi>

On Tue, 27 Jul 2021 at 12:06, Lorenzo Pieralisi
<lorenzo.pieralisi@arm.com> wrote:
>
> On Mon, Jul 26, 2021 at 05:55:33PM +0200, Ard Biesheuvel wrote:
> > On Mon, 26 Jul 2021 at 12:00, Lorenzo Pieralisi
> > <lorenzo.pieralisi@arm.com> wrote:
> > >
> > > The memory attributes attached to memory regions depend on architecture
> > > specific mappings.
> > >
> > > For some memory regions, the attributes specified by firmware (eg
> > > uncached) are not sufficient to determine how a memory region should be
> > > mapped by an OS (for instance a region that is define as uncached in
> > > firmware can be mapped as Normal or Device memory on arm64) and
> > > therefore the OS must be given control on how to map the region to match
> > > the expected mapping behaviour (eg if a mapping is requested with memory
> > > semantics, it must allow unaligned accesses).
> > >
> > > Rework acpi_os_map_memory() and acpi_os_ioremap() back-end to split
> > > them into two separate code paths:
> > >
> > > acpi_os_memmap() -> memory semantics
> > > acpi_os_ioremap() -> MMIO semantics
> > >
> > > The split allows the architectural implementation back-ends to detect
> > > the default memory attributes required by the mapping in question
> > > (ie the mapping API defines the semantics memory vs MMIO) and map the
> > > memory accordingly.
> > >
> > > Link: https://lore.kernel.org/linux-arm-kernel/31ffe8fc-f5ee-2858-26c5-0fd8bdd68702@arm.com
> > > Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
> > > Cc: Ard Biesheuvel <ardb@kernel.org>
> > > Cc: Will Deacon <will@kernel.org>
> > > Cc: Hanjun Guo <guohanjun@huawei.com>
> > > Cc: Sudeep Holla <sudeep.holla@arm.com>
> > > Cc: Catalin Marinas <catalin.marinas@arm.com>
> > > Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>
> >
> > For the patch in general
> >
> > Acked-by: Ard Biesheuvel <ardb@kernel.org>
>
> Thanks !
>
> [...]
>
> > > -void __iomem __ref
> > > -*acpi_os_map_iomem(acpi_physical_address phys, acpi_size size)
> > > +static void __iomem __ref
> > > +*__acpi_os_map_iomem(acpi_physical_address phys, acpi_size size, bool memory)
> > >  {
> > >         struct acpi_ioremap *map;
> > >         void __iomem *virt;
> > > @@ -353,7 +356,7 @@ void __iomem __ref
> > >
> > >         pg_off = round_down(phys, PAGE_SIZE);
> > >         pg_sz = round_up(phys + size, PAGE_SIZE) - pg_off;
> > > -       virt = acpi_map(phys, size);
> > > +       virt = acpi_map(phys, size, memory);
> > >         if (!virt) {
> > >                 mutex_unlock(&acpi_ioremap_lock);
> > >                 kfree(map);
> > > @@ -372,11 +375,17 @@ void __iomem __ref
> > >         mutex_unlock(&acpi_ioremap_lock);
> > >         return map->virt + (phys - map->phys);
> > >  }
> > > +
> > > +void __iomem __ref
> > > +*acpi_os_map_iomem(acpi_physical_address phys, acpi_size size)
> >
> > I am aware that this just duplicated the prototype above, but I think
> > this should be
> >
> > void __iomem *__ref
> >
> > given that the __ref comes after the * in the prototype below.
>
> Yes I just moved/duplicated the prototype above but I believe this is
> consistent with include/acpi/acpi_io.h unless I have not understood
> what you meant ?
>
> It is probably worth changing it in both places to
>
> void __iomem *__ref
>
> ?
>
> I can do that with an additional patch.
>

Yes, as long as they are all mutually consistent. The __ref is not
part of the type at all, so it should not be between the void and the
*, even if the compiler appears to allow it.


> >
> > > +{
> > > +       return __acpi_os_map_iomem(phys, size, false);
> > > +}
> > >  EXPORT_SYMBOL_GPL(acpi_os_map_iomem);
> > >
> > >  void *__ref acpi_os_map_memory(acpi_physical_address phys, acpi_size size)
> > >  {
> > > -       return (void *)acpi_os_map_iomem(phys, size);
> > > +       return (void *)__acpi_os_map_iomem(phys, size, true);
> >
> > I think this should be (__force void *) to shut up sparse address
> > space warnings.
>
> Yes I can add that attribute in an additional patch and rebase this one
> on top of it.
>
> Thanks,
> Lorenzo
>
> >
> > >  }
> > >  EXPORT_SYMBOL_GPL(acpi_os_map_memory);
> > >
> > > diff --git a/include/acpi/acpi_io.h b/include/acpi/acpi_io.h
> > > index 027faa8883aa..a0212e67d6f4 100644
> > > --- a/include/acpi/acpi_io.h
> > > +++ b/include/acpi/acpi_io.h
> > > @@ -14,6 +14,14 @@ static inline void __iomem *acpi_os_ioremap(acpi_physical_address phys,
> > >  }
> > >  #endif
> > >
> > > +#ifndef acpi_os_memmap
> > > +static inline void __iomem *acpi_os_memmap(acpi_physical_address phys,
> > > +                                           acpi_size size)
> > > +{
> > > +       return ioremap_cache(phys, size);
> > > +}
> > > +#endif
> > > +
> > >  extern bool acpi_permanent_mmap;
> > >
> > >  void __iomem __ref
> > > --
> > > 2.31.0
> > >

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2021-07-27 10:10 UTC|newest]

Thread overview: 53+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-07-26 10:00 [PATCH] ACPI: Add memory semantics to acpi_os_map_memory() Lorenzo Pieralisi
2021-07-26 10:00 ` Lorenzo Pieralisi
2021-07-26 15:55 ` Ard Biesheuvel
2021-07-26 15:55   ` Ard Biesheuvel
2021-07-27 10:06   ` Lorenzo Pieralisi
2021-07-27 10:06     ` Lorenzo Pieralisi
2021-07-27 10:09     ` Ard Biesheuvel [this message]
2021-07-27 10:09       ` Ard Biesheuvel
2021-07-27 16:38       ` Lorenzo Pieralisi
2021-07-27 16:38         ` Lorenzo Pieralisi
2021-07-27  4:21 ` Hanjun Guo
2021-07-27  4:21   ` Hanjun Guo
2021-08-02 15:23 ` [PATCH v2 0/3] ACPI: Fix acpi_os_map_memory() memory semantics Lorenzo Pieralisi
2021-08-02 15:23   ` Lorenzo Pieralisi
2021-08-02 15:37   ` Ard Biesheuvel
2021-08-02 15:37     ` Ard Biesheuvel
2021-08-23 10:35   ` [PATCH v3] ACPI: Add memory semantics to acpi_os_map_memory() Lorenzo Pieralisi
2021-08-23 10:46   ` [PATCH RESEND " Lorenzo Pieralisi
2021-08-23 10:46     ` Lorenzo Pieralisi
2021-08-23 12:30     ` Catalin Marinas
2021-08-23 12:30       ` Catalin Marinas
2021-08-25 17:46       ` Rafael J. Wysocki
2021-08-25 17:46         ` Rafael J. Wysocki
2021-08-02 15:23 ` [PATCH v2 1/3] ACPI: osl: Add __force attribute in acpi_os_map_iomem() cast Lorenzo Pieralisi
2021-08-02 15:23   ` Lorenzo Pieralisi
2021-08-10 16:45   ` Christoph Hellwig
2021-08-10 16:45     ` Christoph Hellwig
2021-08-11 10:40     ` Ard Biesheuvel
2021-08-11 10:40       ` Ard Biesheuvel
2021-08-11 14:01       ` Lorenzo Pieralisi
2021-08-11 14:01         ` Lorenzo Pieralisi
2021-08-11 14:08       ` Christoph Hellwig
2021-08-11 14:08         ` Christoph Hellwig
2021-08-11 14:55         ` Lorenzo Pieralisi
2021-08-11 14:55           ` Lorenzo Pieralisi
2021-08-16  9:58           ` Lorenzo Pieralisi
2021-08-16  9:58             ` Lorenzo Pieralisi
2021-08-16 10:21             ` Ard Biesheuvel
2021-08-16 10:21               ` Ard Biesheuvel
2021-08-16 10:59               ` Robin Murphy
2021-08-16 10:59                 ` Robin Murphy
2021-08-16 13:57               ` Rafael J. Wysocki
2021-08-16 13:57                 ` Rafael J. Wysocki
2021-08-02 15:23 ` [PATCH v2 2/3] ACPI: osl: Reorder acpi_os_map_iomem() __ref annotation Lorenzo Pieralisi
2021-08-02 15:23   ` Lorenzo Pieralisi
2021-08-02 15:23 ` [PATCH v2 3/3] ACPI: Add memory semantics to acpi_os_map_memory() Lorenzo Pieralisi
2021-08-02 15:23   ` Lorenzo Pieralisi
2021-08-02 16:46   ` Catalin Marinas
2021-08-02 16:46     ` Catalin Marinas
2021-08-03  9:16     ` Lorenzo Pieralisi
2021-08-03  9:16       ` Lorenzo Pieralisi
2021-08-05 19:02       ` Rafael J. Wysocki
2021-08-05 19:02         ` Rafael J. Wysocki

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAMj1kXHwPXX9MxuF_cw1bq9v+qzH-M4-_ssES8WQq-YP3APthg@mail.gmail.com \
    --to=ardb@kernel.org \
    --cc=catalin.marinas@arm.com \
    --cc=guohanjun@huawei.com \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lorenzo.pieralisi@arm.com \
    --cc=rjw@rjwysocki.net \
    --cc=robin.murphy@arm.com \
    --cc=sudeep.holla@arm.com \
    --cc=vkabatov@redhat.com \
    --cc=will@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.