All of lore.kernel.org
 help / color / mirror / Atom feed
From: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
To: Catalin Marinas <catalin.marinas@arm.com>, rjw@rjwysocki.net
Cc: linux-kernel@vger.kernel.org, Hanjun Guo <guohanjun@huawei.com>,
	Ard Biesheuvel <ardb@kernel.org>, Will Deacon <will@kernel.org>,
	Sudeep Holla <sudeep.holla@arm.com>,
	linux-acpi@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
	Veronika kabatova <vkabatov@redhat.com>,
	Robin Murphy <robin.murphy@arm.com>
Subject: Re: [PATCH v2 3/3] ACPI: Add memory semantics to acpi_os_map_memory()
Date: Tue, 3 Aug 2021 10:16:05 +0100	[thread overview]
Message-ID: <20210803091605.GA9637@lpieralisi> (raw)
In-Reply-To: <20210802164622.GJ18685@arm.com>

On Mon, Aug 02, 2021 at 05:46:22PM +0100, Catalin Marinas wrote:
> On Mon, Aug 02, 2021 at 04:23:59PM +0100, Lorenzo Pieralisi 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
> > Tested-by: Hanjun Guo <guohanjun@huawei.com>
> > Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
> > Acked-by: Ard Biesheuvel <ardb@kernel.org>
> > 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 arm64 bits:
> 
> Acked-by: Catalin Marinas <catalin.marinas@arm.com>
> 
> I presume this will get merged via the ACPI tree?

Thank you, I don't know what's the best option in Rafael's opinion
(of course if he is OK with the patches which are mostly touching
ACPI code).

Lorenzo

WARNING: multiple messages have this Message-ID (diff)
From: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
To: Catalin Marinas <catalin.marinas@arm.com>, rjw@rjwysocki.net
Cc: linux-kernel@vger.kernel.org, Hanjun Guo <guohanjun@huawei.com>,
	Ard Biesheuvel <ardb@kernel.org>, Will Deacon <will@kernel.org>,
	Sudeep Holla <sudeep.holla@arm.com>,
	linux-acpi@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
	Veronika kabatova <vkabatov@redhat.com>,
	Robin Murphy <robin.murphy@arm.com>
Subject: Re: [PATCH v2 3/3] ACPI: Add memory semantics to acpi_os_map_memory()
Date: Tue, 3 Aug 2021 10:16:05 +0100	[thread overview]
Message-ID: <20210803091605.GA9637@lpieralisi> (raw)
In-Reply-To: <20210802164622.GJ18685@arm.com>

On Mon, Aug 02, 2021 at 05:46:22PM +0100, Catalin Marinas wrote:
> On Mon, Aug 02, 2021 at 04:23:59PM +0100, Lorenzo Pieralisi 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
> > Tested-by: Hanjun Guo <guohanjun@huawei.com>
> > Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
> > Acked-by: Ard Biesheuvel <ardb@kernel.org>
> > 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 arm64 bits:
> 
> Acked-by: Catalin Marinas <catalin.marinas@arm.com>
> 
> I presume this will get merged via the ACPI tree?

Thank you, I don't know what's the best option in Rafael's opinion
(of course if he is OK with the patches which are mostly touching
ACPI code).

Lorenzo

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

  reply	other threads:[~2021-08-03  9:16 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
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 [this message]
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=20210803091605.GA9637@lpieralisi \
    --to=lorenzo.pieralisi@arm.com \
    --cc=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=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.