From: Robin Murphy <robin.murphy@arm.com>
To: Christoph Hellwig <hch@infradead.org>,
Shameer Kolothum <shameerali.kolothum.thodi@huawei.com>
Cc: 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 14:53:38 +0100 [thread overview]
Message-ID: <b50cded6-6777-c9c7-7030-a57f28771bc3@arm.com> (raw)
In-Reply-To: <Yk7m8oDPtusDzReK@infradead.org>
On 2022-04-07 14:28, Christoph Hellwig wrote:
>> +static void iort_rmr_desc_check_overlap(struct acpi_iort_rmr_desc *desc, u32 count)
>
> Overly long line.
>
>> void iommu_dma_put_resv_regions(struct device *dev, struct list_head *list)
>> {
>> + if (!is_of_node(dev_iommu_fwspec_get(dev)->iommu_fwnode))
>> + iort_iommu_put_resv_regions(dev, list);
>> +
>> generic_iommu_put_resv_regions(dev, list);
>> }
>
> 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).
Thanks,
Robin.
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
next prev parent reply other threads:[~2022-04-07 13:53 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 via iommu
2022-04-04 12:41 ` [PATCH v9 01/11] ACPI/IORT: Add temporary RMR node flag definitions Shameer Kolothum via iommu
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 via iommu
2022-04-04 12:42 ` [PATCH v9 03/11] ACPI/IORT: Make iort_iommu_msi_get_resv_regions() return void Shameer Kolothum via iommu
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 via iommu
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 via iommu
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 via iommu
2022-04-06 15:47 ` Lorenzo Pieralisi
2022-04-07 13:28 ` Christoph Hellwig
2022-04-07 13:53 ` Robin Murphy [this message]
2022-04-07 13:59 ` Christoph Hellwig
2022-04-19 8:31 ` Shameerali Kolothum Thodi via iommu
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 via iommu
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 via iommu
2022-04-04 12:42 ` [PATCH v9 09/11] iommu/arm-smmu-v3: Refactor arm_smmu_init_bypass_stes() to force bypass Shameer Kolothum via iommu
2022-04-04 12:42 ` [PATCH v9 10/11] iommu/arm-smmu-v3: Get associated RMR info and install bypass STE Shameer Kolothum via iommu
2022-04-04 12:42 ` [PATCH v9 11/11] iommu/arm-smmu: Get associated RMR info and install bypass SMR Shameer Kolothum via iommu
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=b50cded6-6777-c9c7-7030-a57f28771bc3@arm.com \
--to=robin.murphy@arm.com \
--cc=Sami.Mujawar@arm.com \
--cc=guohanjun@huawei.com \
--cc=hch@infradead.org \
--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=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