From: Christoph Hellwig <hch@infradead.org>
To: Robin Murphy <robin.murphy@arm.com>
Cc: Christoph Hellwig <hch@infradead.org>,
Shameer Kolothum <shameerali.kolothum.thodi@huawei.com>,
jon@solid-run.com, linuxarm@huawei.com, steven.price@arm.com,
linux-acpi@vger.kernel.org, iommu@lists.linux-foundation.org,
wanghuiqiang@huawei.com, guohanjun@huawei.com,
yangyicong@huawei.com, Sami.Mujawar@arm.com, will@kernel.org,
linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH v9 06/11] ACPI/IORT: Add support to retrieve IORT RMR reserved regions
Date: Thu, 7 Apr 2022 06:59:32 -0700 [thread overview]
Message-ID: <Yk7uRPG1TwGFPbyY@infradead.org> (raw)
In-Reply-To: <b50cded6-6777-c9c7-7030-a57f28771bc3@arm.com>
On Thu, Apr 07, 2022 at 02:53:38PM +0100, Robin Murphy wrote:
> > Why can't this just go into generic_iommu_put_resv_regions? The idea
> > that the iommu low-level drivers need to call into dma-iommu which is
> > a consumer of the IOMMU API is odd. Especially if that just calls out
> > to ACPI code and generic IOMMU code only anyway.
>
> Because assuming ACPI means IORT is not generic. Part of the aim in adding
> the union to iommu_resv_region is that stuff like AMD's unity_map_entry and
> Intel's dmar_rmrr_unit can be folded into it as well, and their reserved
> region handling correspondingly simplified too.
>
> The iommu_dma_{get,put}_resv_region() helpers are kind of intended to be
> specific to the fwnode mechanism which deals with IORT and devicetree (once
> the reserved region bindings are fully worked out).
But IORT is not driver₋specific code. So we'll need a USE_IORT flag
somewhere in core IOMMU code instead of trying to stuff this into
driver operations. and dma-iommu mostly certainly implies IORT even
less than ACPI.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2022-04-07 14:00 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-04-04 12:41 [PATCH v9 00/11] ACPI/IORT: Support for IORT RMR node Shameer Kolothum
2022-04-04 12:41 ` [PATCH v9 01/11] ACPI/IORT: Add temporary RMR node flag definitions Shameer Kolothum
2022-04-06 15:53 ` Lorenzo Pieralisi
2022-04-04 12:42 ` [PATCH v9 02/11] iommu: Introduce a union to struct iommu_resv_region Shameer Kolothum
2022-04-04 12:42 ` [PATCH v9 03/11] ACPI/IORT: Make iort_iommu_msi_get_resv_regions() return void Shameer Kolothum
2022-04-06 15:12 ` Lorenzo Pieralisi
2022-04-04 12:42 ` [PATCH v9 04/11] ACPI/IORT: Provide a generic helper to retrieve reserve regions Shameer Kolothum
2022-04-06 15:54 ` Lorenzo Pieralisi
2022-04-04 12:42 ` [PATCH v9 05/11] iommu/dma: Introduce a helper to remove reserved regions Shameer Kolothum
2022-04-07 13:26 ` Christoph Hellwig
2022-04-04 12:42 ` [PATCH v9 06/11] ACPI/IORT: Add support to retrieve IORT RMR " Shameer Kolothum
2022-04-06 15:47 ` Lorenzo Pieralisi
2022-04-07 13:28 ` Christoph Hellwig
2022-04-07 13:53 ` Robin Murphy
2022-04-07 13:59 ` Christoph Hellwig [this message]
2022-04-19 8:31 ` Shameerali Kolothum Thodi
2022-04-19 9:04 ` Christoph Hellwig
2022-04-04 12:42 ` [PATCH v9 07/11] ACPI/IORT: Add a helper to retrieve RMR info directly Shameer Kolothum
2022-04-06 15:51 ` Lorenzo Pieralisi
2022-04-04 12:42 ` [PATCH v9 08/11] iommu/arm-smmu-v3: Introduce strtab init helper Shameer Kolothum
2022-04-04 12:42 ` [PATCH v9 09/11] iommu/arm-smmu-v3: Refactor arm_smmu_init_bypass_stes() to force bypass Shameer Kolothum
2022-04-04 12:42 ` [PATCH v9 10/11] iommu/arm-smmu-v3: Get associated RMR info and install bypass STE Shameer Kolothum
2022-04-04 12:42 ` [PATCH v9 11/11] iommu/arm-smmu: Get associated RMR info and install bypass SMR Shameer Kolothum
2022-04-07 15:43 ` [PATCH v9 00/11] ACPI/IORT: Support for IORT RMR node Steven Price
2022-04-19 14:50 ` Laurentiu Tudor
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=Yk7uRPG1TwGFPbyY@infradead.org \
--to=hch@infradead.org \
--cc=Sami.Mujawar@arm.com \
--cc=guohanjun@huawei.com \
--cc=iommu@lists.linux-foundation.org \
--cc=jon@solid-run.com \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linuxarm@huawei.com \
--cc=robin.murphy@arm.com \
--cc=shameerali.kolothum.thodi@huawei.com \
--cc=steven.price@arm.com \
--cc=wanghuiqiang@huawei.com \
--cc=will@kernel.org \
--cc=yangyicong@huawei.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).