From: Shameerali Kolothum Thodi <shameerali.kolothum.thodi@huawei.com>
To: Robin Murphy <robin.murphy@arm.com>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
"linux-acpi@vger.kernel.org" <linux-acpi@vger.kernel.org>,
"iommu@lists.linux-foundation.org"
<iommu@lists.linux-foundation.org>
Cc: "jon@solid-run.com" <jon@solid-run.com>,
Linuxarm <linuxarm@huawei.com>,
"steven.price@arm.com" <steven.price@arm.com>,
"Guohanjun (Hanjun Guo)" <guohanjun@huawei.com>,
yangyicong <yangyicong@huawei.com>,
"Sami.Mujawar@arm.com" <Sami.Mujawar@arm.com>,
"will@kernel.org" <will@kernel.org>,
wanghuiqiang <wanghuiqiang@huawei.com>
Subject: RE: [PATCH v8 05/11] ACPI/IORT: Add a helper to retrieve RMR memory regions
Date: Wed, 23 Mar 2022 16:06:04 +0000 [thread overview]
Message-ID: <ad7ae652a2b54261a522008a25238039@huawei.com> (raw)
In-Reply-To: <479ae561-e03e-163e-f945-d0c8fdf8dcea@arm.com>
> -----Original Message-----
> From: Robin Murphy [mailto:robin.murphy@arm.com]
> Sent: 22 March 2022 19:09
> To: Shameerali Kolothum Thodi <shameerali.kolothum.thodi@huawei.com>;
> linux-arm-kernel@lists.infradead.org; linux-acpi@vger.kernel.org;
> iommu@lists.linux-foundation.org
> Cc: jon@solid-run.com; Linuxarm <linuxarm@huawei.com>;
> steven.price@arm.com; Guohanjun (Hanjun Guo) <guohanjun@huawei.com>;
> yangyicong <yangyicong@huawei.com>; Sami.Mujawar@arm.com;
> will@kernel.org; wanghuiqiang <wanghuiqiang@huawei.com>
> Subject: Re: [PATCH v8 05/11] ACPI/IORT: Add a helper to retrieve RMR
> memory regions
>
> On 2022-02-21 15:43, Shameer Kolothum via iommu wrote:
> > Add helper functions (iort_iommu_get/put_rmrs()) that
> > retrieves/releases RMR memory descriptors associated
> > with a given IOMMU. This will be used by IOMMU drivers
> > to set up necessary mappings.
> >
> > Invoke it from the generic iommu helper functions.
>
> iommu_dma_get_resv_regions() already exists - please extend that rather
> than adding a parallel implementation of the same thing but different.
> IORT should export a single get_resv_regions helper which combines the
> new RMRs with the existing MSI workaround, and a separate "do I need to
> bypass this StreamID" helper for the SMMU drivers to call directly at
> reset time, since the latter isn't really an iommu-dma responsibility.
Right. I actually had couple of back and forth on the interfaces and settled
on this mainly because it just requires a single interface from IORT for both
get_resv_regions() and SMMU driver reset bypass path.
ie, iort_iommu_get/put_rmrs()).
But agree the above comment is also valid.
> I'm happy to do that just by shuffling wrappers around for now - we can
> come back and streamline the code properly afterwards - but the sheer
> amount of indirection currently at play here is so hard to follow that
> it's not even all that easy to see how it's crossing abstraction levels
> improperly.
Please find below the revised ones. Please take a look and let me know.
Thanks,
Shameer
iommu-dma:
void iommu_dma_get_resv_regions(struct device *dev, struct list_head *list) {
if (!is_of_node(dev_iommu_fwspec_get(dev)->iommu_fwnode))
iort_iommu_get_resv_regions(dev, list);
}
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);
}
iort:
void iort_iommu_get_resv_regions(struct device *dev, struct list_head *head) {
struct iommu_fwspec *fwspec = dev_iommu_fwspec_get(dev);
iort_iommu_msi_get_resv_regions(dev, head);
iort_iommu_get_rmrs(fwspec->iommu_fwnode, dev, head);
}
void iort_iommu_put_resv_regions(struct device *dev, struct list_head *head) {
./*Free both RMRs and HW MSI ones */
}
/* The below ones will be directly called from SMMU drivers during reset */
void iort_get_rmr_sids(struct fwnode_handle *iommu_fwnode, struct list_head *head) {
iort_iommu_get_rmrs(iommu_fwnode, NULL, head); }
}
void iort_put_rmr_sids(struct fwnode_handle *iommu_fwnode, struct list_head *head) {
iort_iommu_put_resv_regions(NULL, head);
}
next prev parent reply other threads:[~2022-03-23 16:06 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-02-21 15:43 [PATCH v8 00/11] ACPI/IORT: Support for IORT RMR node Shameer Kolothum
2022-02-21 15:43 ` [PATCH v8 01/11] ACPI/IORT: Add temporary RMR node flag definitions Shameer Kolothum
2022-03-22 19:31 ` Robin Murphy
2022-02-21 15:43 ` [PATCH v8 02/11] iommu: Introduce a union to struct iommu_resv_region Shameer Kolothum
2022-03-22 18:27 ` Robin Murphy
2022-03-23 15:55 ` Shameerali Kolothum Thodi
2022-02-21 15:43 ` [PATCH v8 03/11] ACPI/IORT: Add helper functions to parse RMR nodes Shameer Kolothum
2022-02-24 10:13 ` Lorenzo Pieralisi
2022-02-25 17:31 ` Shameerali Kolothum Thodi
2022-03-10 10:32 ` Eric Auger
2022-03-10 10:45 ` Shameerali Kolothum Thodi
2022-02-21 15:43 ` [PATCH v8 04/11] iommu/dma: Introduce generic helper to retrieve RMR info Shameer Kolothum
2022-02-21 15:43 ` [PATCH v8 05/11] ACPI/IORT: Add a helper to retrieve RMR memory regions Shameer Kolothum
2022-02-23 18:05 ` Lorenzo Pieralisi
2022-03-22 19:08 ` Robin Murphy
2022-03-23 16:06 ` Shameerali Kolothum Thodi [this message]
2022-03-25 17:49 ` Robin Murphy
2022-02-21 15:43 ` [PATCH v8 06/11] iommu/arm-smmu-v3: Introduce strtab init helper Shameer Kolothum
2022-02-21 15:43 ` [PATCH v8 07/11] iommu/arm-smmu-v3: Refactor arm_smmu_init_bypass_stes() to force bypass Shameer Kolothum
2022-02-21 15:43 ` [PATCH v8 08/11] iommu/arm-smmu-v3: Get associated RMR info and install bypass STE Shameer Kolothum
2022-02-21 15:43 ` [PATCH v8 09/11] iommu/arm-smmu: Get associated RMR info and install bypass SMR Shameer Kolothum
2022-02-21 15:43 ` [PATCH v8 10/11] iommu/arm-smmu-v3: Reserve any RMR regions associated with a dev Shameer Kolothum
2022-03-22 19:12 ` Robin Murphy
2022-02-21 15:43 ` [PATCH v8 11/11] iommu/arm-smmu: " Shameer Kolothum
2022-03-03 10:37 ` [PATCH v8 00/11] ACPI/IORT: Support for IORT RMR node Steven Price
2022-03-03 13:02 ` Shameerali Kolothum Thodi
2022-03-11 8:06 ` Eric Auger
2022-03-11 13:23 ` Shameerali Kolothum Thodi
2022-03-11 8:19 ` Eric Auger
2022-03-11 10:34 ` Robin Murphy
2022-03-14 10:37 ` Eric Auger
2022-03-14 10:43 ` Ard Biesheuvel
2022-03-14 11:30 ` Lorenzo Pieralisi
2022-03-15 17:53 ` Eric Auger
2022-03-17 15:30 ` Shameerali Kolothum Thodi
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=ad7ae652a2b54261a522008a25238039@huawei.com \
--to=shameerali.kolothum.thodi@huawei.com \
--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=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