All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jon Nettleton <jon@solid-run.com>
To: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Cc: Shameer Kolothum <shameerali.kolothum.thodi@huawei.com>,
	linux-arm-kernel <linux-arm-kernel@lists.infradead.org>,
	ACPI Devel Maling List <linux-acpi@vger.kernel.org>,
	iommu@lists.linux-foundation.org, Linuxarm <linuxarm@huawei.com>,
	joro@8bytes.org, Robin Murphy <robin.murphy@arm.com>,
	Will Deacon <will@kernel.org>,
	wanghuiqiang <wanghuiqiang@huawei.com>,
	Hanjun Guo <guohanjun@huawei.com>,
	Steven Price <steven.price@arm.com>,
	Sami Mujawar <Sami.Mujawar@arm.com>,
	eric.auger@redhat.com, yangyicong <yangyicong@huawei.com>
Subject: Re: [PATCH v7 2/9] ACPI/IORT: Add support for RMR node parsing
Date: Thu, 5 Aug 2021 18:31:47 +0200	[thread overview]
Message-ID: <CABdtJHuhpnASw8NQb7dRo42Z5NqOzvtvjoyndsJ2jd+Qvsq7vQ@mail.gmail.com> (raw)
In-Reply-To: <20210805160319.GB23085@lpieralisi>

On Thu, Aug 5, 2021 at 6:03 PM Lorenzo Pieralisi
<lorenzo.pieralisi@arm.com> wrote:
>
> On Thu, Aug 05, 2021 at 09:07:17AM +0100, Shameer Kolothum wrote:
>
> [...]
>
> > +static void __init iort_node_get_rmr_info(struct acpi_iort_node *iort_node)
> > +{
> > +     struct acpi_iort_node *smmu;
> > +     struct acpi_iort_rmr *rmr;
> > +     struct acpi_iort_rmr_desc *rmr_desc;
> > +     u32 map_count = iort_node->mapping_count;
> > +     u32 sid;
> > +     int i;
> > +
> > +     if (!iort_node->mapping_offset || map_count != 1) {
> > +             pr_err(FW_BUG "Invalid ID mapping, skipping RMR node %p\n",
> > +                    iort_node);
> > +             return;
> > +     }
> > +
> > +     /* Retrieve associated smmu and stream id */
> > +     smmu = iort_node_get_id(iort_node, &sid, 0);
> > +     if (!smmu) {
> > +             pr_err(FW_BUG "Invalid SMMU reference, skipping RMR node %p\n",
> > +                    iort_node);
> > +             return;
> > +     }
> > +
> > +     /* Retrieve RMR data */
> > +     rmr = (struct acpi_iort_rmr *)iort_node->node_data;
> > +     if (!rmr->rmr_offset || !rmr->rmr_count) {
> > +             pr_err(FW_BUG "Invalid RMR descriptor array, skipping RMR node %p\n",
> > +                    iort_node);
> > +             return;
> > +     }
> > +
> > +     rmr_desc = ACPI_ADD_PTR(struct acpi_iort_rmr_desc, iort_node,
> > +                             rmr->rmr_offset);
> > +
> > +     iort_rmr_desc_check_overlap(rmr_desc, rmr->rmr_count);
> > +
> > +     for (i = 0; i < rmr->rmr_count; i++, rmr_desc++) {
> > +             struct iommu_resv_region *region;
> > +             enum iommu_resv_type type;
> > +             int prot = IOMMU_READ | IOMMU_WRITE;
> > +             u64 addr = rmr_desc->base_address, size = rmr_desc->length;
> > +
> > +             if (!IS_ALIGNED(addr, SZ_64K) || !IS_ALIGNED(size, SZ_64K)) {
> > +                     /* PAGE align base addr and size */
> > +                     addr &= PAGE_MASK;
> > +                     size = PAGE_ALIGN(size + offset_in_page(rmr_desc->base_address));
> > +
> > +                     pr_err(FW_BUG "RMR descriptor[0x%llx - 0x%llx] not aligned to 64K, continue with [0x%llx - 0x%llx]\n",
> > +                            rmr_desc->base_address,
> > +                            rmr_desc->base_address + rmr_desc->length - 1,
> > +                            addr, addr + size - 1);
> > +             }
> > +             if (rmr->flags & IOMMU_RMR_REMAP_PERMITTED) {
> > +                     type = IOMMU_RESV_DIRECT_RELAXABLE;
> > +                     /*
> > +                      * Set IOMMU_CACHE as IOMMU_RESV_DIRECT_RELAXABLE is
> > +                      * normally used for allocated system memory that is
> > +                      * then used for device specific reserved regions.
> > +                      */
> > +                     prot |= IOMMU_CACHE;
> > +             } else {
> > +                     type = IOMMU_RESV_DIRECT;
> > +                     /*
> > +                      * Set IOMMU_MMIO as IOMMU_RESV_DIRECT is normally used
> > +                      * for device memory like MSI doorbell.
> > +                      */
> > +                     prot |= IOMMU_MMIO;
> > +             }
>
> On the prot value assignment based on the remapping flag, I'd like to
> hear Robin/Joerg's opinion, I'd avoid being in a situation where
> "normally" this would work but then we have to quirk it.
>
> Is this a valid assumption _always_ ?

These assumptions were made based on the historic use cases I could
find reading the history.  There aren't many known examples "in the wild"
because so far we haven't had a mechanism other than quirks based
around device-tree implementations.

Ultimately I believe the proper solution will need to be another flag
in the RMR table that specifies the type of memory an RMR Node
describes, not just the base and length.

-Jon

>
> Thanks,
> Lorenzo
>
> > +
> > +             region = iommu_alloc_resv_region(addr, size, prot, type);
> > +             if (region) {
> > +                     region->fw_data.rmr.flags = rmr->flags;
> > +                     region->fw_data.rmr.sid = sid;
> > +                     region->fw_data.rmr.smmu = smmu;
> > +                     list_add_tail(&region->list, &iort_rmr_list);
> > +             }
> > +     }
> > +}
> > +
> > +static void __init iort_parse_rmr(void)
> > +{
> > +     struct acpi_iort_node *iort_node, *iort_end;
> > +     struct acpi_table_iort *iort;
> > +     int i;
> > +
> > +     if (iort_table->revision < 3)
> > +             return;
> > +
> > +     iort = (struct acpi_table_iort *)iort_table;
> > +
> > +     iort_node = ACPI_ADD_PTR(struct acpi_iort_node, iort,
> > +                              iort->node_offset);
> > +     iort_end = ACPI_ADD_PTR(struct acpi_iort_node, iort,
> > +                             iort_table->length);
> > +
> > +     for (i = 0; i < iort->node_count; i++) {
> > +             if (WARN_TAINT(iort_node >= iort_end, TAINT_FIRMWARE_WORKAROUND,
> > +                            "IORT node pointer overflows, bad table!\n"))
> > +                     return;
> > +
> > +             if (iort_node->type == ACPI_IORT_NODE_RMR)
> > +                     iort_node_get_rmr_info(iort_node);
> > +
> > +             iort_node = ACPI_ADD_PTR(struct acpi_iort_node, iort_node,
> > +                                      iort_node->length);
> > +     }
> > +}
> >
> >  static void __init iort_init_platform_devices(void)
> >  {
> > @@ -1636,6 +1767,7 @@ void __init acpi_iort_init(void)
> >       }
> >
> >       iort_init_platform_devices();
> > +     iort_parse_rmr();
> >  }
> >
> >  #ifdef CONFIG_ZONE_DMA
> > --
> > 2.17.1
> >

WARNING: multiple messages have this Message-ID (diff)
From: Jon Nettleton <jon@solid-run.com>
To: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Cc: Will Deacon <will@kernel.org>, Linuxarm <linuxarm@huawei.com>,
	Steven Price <steven.price@arm.com>,
	ACPI Devel Maling List <linux-acpi@vger.kernel.org>,
	iommu@lists.linux-foundation.org,
	wanghuiqiang <wanghuiqiang@huawei.com>,
	Hanjun Guo <guohanjun@huawei.com>,
	yangyicong <yangyicong@huawei.com>,
	Sami Mujawar <Sami.Mujawar@arm.com>,
	Robin Murphy <robin.murphy@arm.com>,
	linux-arm-kernel <linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH v7 2/9] ACPI/IORT: Add support for RMR node parsing
Date: Thu, 5 Aug 2021 18:31:47 +0200	[thread overview]
Message-ID: <CABdtJHuhpnASw8NQb7dRo42Z5NqOzvtvjoyndsJ2jd+Qvsq7vQ@mail.gmail.com> (raw)
In-Reply-To: <20210805160319.GB23085@lpieralisi>

On Thu, Aug 5, 2021 at 6:03 PM Lorenzo Pieralisi
<lorenzo.pieralisi@arm.com> wrote:
>
> On Thu, Aug 05, 2021 at 09:07:17AM +0100, Shameer Kolothum wrote:
>
> [...]
>
> > +static void __init iort_node_get_rmr_info(struct acpi_iort_node *iort_node)
> > +{
> > +     struct acpi_iort_node *smmu;
> > +     struct acpi_iort_rmr *rmr;
> > +     struct acpi_iort_rmr_desc *rmr_desc;
> > +     u32 map_count = iort_node->mapping_count;
> > +     u32 sid;
> > +     int i;
> > +
> > +     if (!iort_node->mapping_offset || map_count != 1) {
> > +             pr_err(FW_BUG "Invalid ID mapping, skipping RMR node %p\n",
> > +                    iort_node);
> > +             return;
> > +     }
> > +
> > +     /* Retrieve associated smmu and stream id */
> > +     smmu = iort_node_get_id(iort_node, &sid, 0);
> > +     if (!smmu) {
> > +             pr_err(FW_BUG "Invalid SMMU reference, skipping RMR node %p\n",
> > +                    iort_node);
> > +             return;
> > +     }
> > +
> > +     /* Retrieve RMR data */
> > +     rmr = (struct acpi_iort_rmr *)iort_node->node_data;
> > +     if (!rmr->rmr_offset || !rmr->rmr_count) {
> > +             pr_err(FW_BUG "Invalid RMR descriptor array, skipping RMR node %p\n",
> > +                    iort_node);
> > +             return;
> > +     }
> > +
> > +     rmr_desc = ACPI_ADD_PTR(struct acpi_iort_rmr_desc, iort_node,
> > +                             rmr->rmr_offset);
> > +
> > +     iort_rmr_desc_check_overlap(rmr_desc, rmr->rmr_count);
> > +
> > +     for (i = 0; i < rmr->rmr_count; i++, rmr_desc++) {
> > +             struct iommu_resv_region *region;
> > +             enum iommu_resv_type type;
> > +             int prot = IOMMU_READ | IOMMU_WRITE;
> > +             u64 addr = rmr_desc->base_address, size = rmr_desc->length;
> > +
> > +             if (!IS_ALIGNED(addr, SZ_64K) || !IS_ALIGNED(size, SZ_64K)) {
> > +                     /* PAGE align base addr and size */
> > +                     addr &= PAGE_MASK;
> > +                     size = PAGE_ALIGN(size + offset_in_page(rmr_desc->base_address));
> > +
> > +                     pr_err(FW_BUG "RMR descriptor[0x%llx - 0x%llx] not aligned to 64K, continue with [0x%llx - 0x%llx]\n",
> > +                            rmr_desc->base_address,
> > +                            rmr_desc->base_address + rmr_desc->length - 1,
> > +                            addr, addr + size - 1);
> > +             }
> > +             if (rmr->flags & IOMMU_RMR_REMAP_PERMITTED) {
> > +                     type = IOMMU_RESV_DIRECT_RELAXABLE;
> > +                     /*
> > +                      * Set IOMMU_CACHE as IOMMU_RESV_DIRECT_RELAXABLE is
> > +                      * normally used for allocated system memory that is
> > +                      * then used for device specific reserved regions.
> > +                      */
> > +                     prot |= IOMMU_CACHE;
> > +             } else {
> > +                     type = IOMMU_RESV_DIRECT;
> > +                     /*
> > +                      * Set IOMMU_MMIO as IOMMU_RESV_DIRECT is normally used
> > +                      * for device memory like MSI doorbell.
> > +                      */
> > +                     prot |= IOMMU_MMIO;
> > +             }
>
> On the prot value assignment based on the remapping flag, I'd like to
> hear Robin/Joerg's opinion, I'd avoid being in a situation where
> "normally" this would work but then we have to quirk it.
>
> Is this a valid assumption _always_ ?

These assumptions were made based on the historic use cases I could
find reading the history.  There aren't many known examples "in the wild"
because so far we haven't had a mechanism other than quirks based
around device-tree implementations.

Ultimately I believe the proper solution will need to be another flag
in the RMR table that specifies the type of memory an RMR Node
describes, not just the base and length.

-Jon

>
> Thanks,
> Lorenzo
>
> > +
> > +             region = iommu_alloc_resv_region(addr, size, prot, type);
> > +             if (region) {
> > +                     region->fw_data.rmr.flags = rmr->flags;
> > +                     region->fw_data.rmr.sid = sid;
> > +                     region->fw_data.rmr.smmu = smmu;
> > +                     list_add_tail(&region->list, &iort_rmr_list);
> > +             }
> > +     }
> > +}
> > +
> > +static void __init iort_parse_rmr(void)
> > +{
> > +     struct acpi_iort_node *iort_node, *iort_end;
> > +     struct acpi_table_iort *iort;
> > +     int i;
> > +
> > +     if (iort_table->revision < 3)
> > +             return;
> > +
> > +     iort = (struct acpi_table_iort *)iort_table;
> > +
> > +     iort_node = ACPI_ADD_PTR(struct acpi_iort_node, iort,
> > +                              iort->node_offset);
> > +     iort_end = ACPI_ADD_PTR(struct acpi_iort_node, iort,
> > +                             iort_table->length);
> > +
> > +     for (i = 0; i < iort->node_count; i++) {
> > +             if (WARN_TAINT(iort_node >= iort_end, TAINT_FIRMWARE_WORKAROUND,
> > +                            "IORT node pointer overflows, bad table!\n"))
> > +                     return;
> > +
> > +             if (iort_node->type == ACPI_IORT_NODE_RMR)
> > +                     iort_node_get_rmr_info(iort_node);
> > +
> > +             iort_node = ACPI_ADD_PTR(struct acpi_iort_node, iort_node,
> > +                                      iort_node->length);
> > +     }
> > +}
> >
> >  static void __init iort_init_platform_devices(void)
> >  {
> > @@ -1636,6 +1767,7 @@ void __init acpi_iort_init(void)
> >       }
> >
> >       iort_init_platform_devices();
> > +     iort_parse_rmr();
> >  }
> >
> >  #ifdef CONFIG_ZONE_DMA
> > --
> > 2.17.1
> >
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

WARNING: multiple messages have this Message-ID (diff)
From: Jon Nettleton <jon@solid-run.com>
To: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Cc: Shameer Kolothum <shameerali.kolothum.thodi@huawei.com>,
	 linux-arm-kernel <linux-arm-kernel@lists.infradead.org>,
	 ACPI Devel Maling List <linux-acpi@vger.kernel.org>,
	iommu@lists.linux-foundation.org,  Linuxarm <linuxarm@huawei.com>,
	joro@8bytes.org, Robin Murphy <robin.murphy@arm.com>,
	 Will Deacon <will@kernel.org>,
	wanghuiqiang <wanghuiqiang@huawei.com>,
	 Hanjun Guo <guohanjun@huawei.com>,
	Steven Price <steven.price@arm.com>,
	 Sami Mujawar <Sami.Mujawar@arm.com>,
	eric.auger@redhat.com,  yangyicong <yangyicong@huawei.com>
Subject: Re: [PATCH v7 2/9] ACPI/IORT: Add support for RMR node parsing
Date: Thu, 5 Aug 2021 18:31:47 +0200	[thread overview]
Message-ID: <CABdtJHuhpnASw8NQb7dRo42Z5NqOzvtvjoyndsJ2jd+Qvsq7vQ@mail.gmail.com> (raw)
In-Reply-To: <20210805160319.GB23085@lpieralisi>

On Thu, Aug 5, 2021 at 6:03 PM Lorenzo Pieralisi
<lorenzo.pieralisi@arm.com> wrote:
>
> On Thu, Aug 05, 2021 at 09:07:17AM +0100, Shameer Kolothum wrote:
>
> [...]
>
> > +static void __init iort_node_get_rmr_info(struct acpi_iort_node *iort_node)
> > +{
> > +     struct acpi_iort_node *smmu;
> > +     struct acpi_iort_rmr *rmr;
> > +     struct acpi_iort_rmr_desc *rmr_desc;
> > +     u32 map_count = iort_node->mapping_count;
> > +     u32 sid;
> > +     int i;
> > +
> > +     if (!iort_node->mapping_offset || map_count != 1) {
> > +             pr_err(FW_BUG "Invalid ID mapping, skipping RMR node %p\n",
> > +                    iort_node);
> > +             return;
> > +     }
> > +
> > +     /* Retrieve associated smmu and stream id */
> > +     smmu = iort_node_get_id(iort_node, &sid, 0);
> > +     if (!smmu) {
> > +             pr_err(FW_BUG "Invalid SMMU reference, skipping RMR node %p\n",
> > +                    iort_node);
> > +             return;
> > +     }
> > +
> > +     /* Retrieve RMR data */
> > +     rmr = (struct acpi_iort_rmr *)iort_node->node_data;
> > +     if (!rmr->rmr_offset || !rmr->rmr_count) {
> > +             pr_err(FW_BUG "Invalid RMR descriptor array, skipping RMR node %p\n",
> > +                    iort_node);
> > +             return;
> > +     }
> > +
> > +     rmr_desc = ACPI_ADD_PTR(struct acpi_iort_rmr_desc, iort_node,
> > +                             rmr->rmr_offset);
> > +
> > +     iort_rmr_desc_check_overlap(rmr_desc, rmr->rmr_count);
> > +
> > +     for (i = 0; i < rmr->rmr_count; i++, rmr_desc++) {
> > +             struct iommu_resv_region *region;
> > +             enum iommu_resv_type type;
> > +             int prot = IOMMU_READ | IOMMU_WRITE;
> > +             u64 addr = rmr_desc->base_address, size = rmr_desc->length;
> > +
> > +             if (!IS_ALIGNED(addr, SZ_64K) || !IS_ALIGNED(size, SZ_64K)) {
> > +                     /* PAGE align base addr and size */
> > +                     addr &= PAGE_MASK;
> > +                     size = PAGE_ALIGN(size + offset_in_page(rmr_desc->base_address));
> > +
> > +                     pr_err(FW_BUG "RMR descriptor[0x%llx - 0x%llx] not aligned to 64K, continue with [0x%llx - 0x%llx]\n",
> > +                            rmr_desc->base_address,
> > +                            rmr_desc->base_address + rmr_desc->length - 1,
> > +                            addr, addr + size - 1);
> > +             }
> > +             if (rmr->flags & IOMMU_RMR_REMAP_PERMITTED) {
> > +                     type = IOMMU_RESV_DIRECT_RELAXABLE;
> > +                     /*
> > +                      * Set IOMMU_CACHE as IOMMU_RESV_DIRECT_RELAXABLE is
> > +                      * normally used for allocated system memory that is
> > +                      * then used for device specific reserved regions.
> > +                      */
> > +                     prot |= IOMMU_CACHE;
> > +             } else {
> > +                     type = IOMMU_RESV_DIRECT;
> > +                     /*
> > +                      * Set IOMMU_MMIO as IOMMU_RESV_DIRECT is normally used
> > +                      * for device memory like MSI doorbell.
> > +                      */
> > +                     prot |= IOMMU_MMIO;
> > +             }
>
> On the prot value assignment based on the remapping flag, I'd like to
> hear Robin/Joerg's opinion, I'd avoid being in a situation where
> "normally" this would work but then we have to quirk it.
>
> Is this a valid assumption _always_ ?

These assumptions were made based on the historic use cases I could
find reading the history.  There aren't many known examples "in the wild"
because so far we haven't had a mechanism other than quirks based
around device-tree implementations.

Ultimately I believe the proper solution will need to be another flag
in the RMR table that specifies the type of memory an RMR Node
describes, not just the base and length.

-Jon

>
> Thanks,
> Lorenzo
>
> > +
> > +             region = iommu_alloc_resv_region(addr, size, prot, type);
> > +             if (region) {
> > +                     region->fw_data.rmr.flags = rmr->flags;
> > +                     region->fw_data.rmr.sid = sid;
> > +                     region->fw_data.rmr.smmu = smmu;
> > +                     list_add_tail(&region->list, &iort_rmr_list);
> > +             }
> > +     }
> > +}
> > +
> > +static void __init iort_parse_rmr(void)
> > +{
> > +     struct acpi_iort_node *iort_node, *iort_end;
> > +     struct acpi_table_iort *iort;
> > +     int i;
> > +
> > +     if (iort_table->revision < 3)
> > +             return;
> > +
> > +     iort = (struct acpi_table_iort *)iort_table;
> > +
> > +     iort_node = ACPI_ADD_PTR(struct acpi_iort_node, iort,
> > +                              iort->node_offset);
> > +     iort_end = ACPI_ADD_PTR(struct acpi_iort_node, iort,
> > +                             iort_table->length);
> > +
> > +     for (i = 0; i < iort->node_count; i++) {
> > +             if (WARN_TAINT(iort_node >= iort_end, TAINT_FIRMWARE_WORKAROUND,
> > +                            "IORT node pointer overflows, bad table!\n"))
> > +                     return;
> > +
> > +             if (iort_node->type == ACPI_IORT_NODE_RMR)
> > +                     iort_node_get_rmr_info(iort_node);
> > +
> > +             iort_node = ACPI_ADD_PTR(struct acpi_iort_node, iort_node,
> > +                                      iort_node->length);
> > +     }
> > +}
> >
> >  static void __init iort_init_platform_devices(void)
> >  {
> > @@ -1636,6 +1767,7 @@ void __init acpi_iort_init(void)
> >       }
> >
> >       iort_init_platform_devices();
> > +     iort_parse_rmr();
> >  }
> >
> >  #ifdef CONFIG_ZONE_DMA
> > --
> > 2.17.1
> >

_______________________________________________
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-05 16:32 UTC|newest]

Thread overview: 150+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-08-05  8:07 [PATCH v7 0/9] ACPI/IORT: Support for IORT RMR node Shameer Kolothum
2021-08-05  8:07 ` Shameer Kolothum
2021-08-05  8:07 ` Shameer Kolothum
2021-08-05  8:07 ` [PATCH v7 1/9] iommu: Introduce a union to struct iommu_resv_region Shameer Kolothum
2021-08-05  8:07   ` Shameer Kolothum
2021-08-05  8:07   ` Shameer Kolothum
2021-08-20 10:22   ` Steven Price
2021-08-20 10:22     ` Steven Price
2021-08-20 10:22     ` Steven Price
2021-10-08 12:14   ` Robin Murphy
2021-10-08 12:14     ` Robin Murphy
2021-10-08 12:14     ` Robin Murphy
2021-10-09  6:57     ` Jon Nettleton
2021-10-09  6:57       ` Jon Nettleton
2021-10-09  6:57       ` Jon Nettleton
2021-10-11  5:47       ` Shameerali Kolothum Thodi
2021-10-11  5:47         ` Shameerali Kolothum Thodi
2021-10-11  5:47         ` Shameerali Kolothum Thodi
2021-10-11 13:47         ` Robin Murphy
2021-10-11 13:47           ` Robin Murphy
2021-10-11 13:47           ` Robin Murphy
2021-08-05  8:07 ` [PATCH v7 2/9] ACPI/IORT: Add support for RMR node parsing Shameer Kolothum
2021-08-05  8:07   ` Shameer Kolothum
2021-08-05  8:07   ` Shameer Kolothum
2021-08-05 16:03   ` Lorenzo Pieralisi
2021-08-05 16:03     ` Lorenzo Pieralisi
2021-08-05 16:03     ` Lorenzo Pieralisi
2021-08-05 16:31     ` Jon Nettleton [this message]
2021-08-05 16:31       ` Jon Nettleton
2021-08-05 16:31       ` Jon Nettleton
2021-08-05 18:37     ` Laurentiu Tudor
2021-08-05 18:37       ` Laurentiu Tudor
2021-08-05 18:37       ` Laurentiu Tudor
2021-09-06 17:44     ` Robin Murphy
2021-09-06 17:44       ` Robin Murphy
2021-09-06 17:44       ` Robin Murphy
2021-09-06 19:51       ` Jon Nettleton
2021-09-06 19:51         ` Jon Nettleton
2021-09-06 19:51         ` Jon Nettleton
2021-09-16  7:26         ` Shameerali Kolothum Thodi
2021-09-16  7:26           ` Shameerali Kolothum Thodi
2021-09-16  7:26           ` Shameerali Kolothum Thodi
2021-09-16  7:52           ` Jon Nettleton
2021-09-16  7:52             ` Jon Nettleton
2021-09-16  7:52             ` Jon Nettleton
2021-09-16  8:26             ` Shameerali Kolothum Thodi
2021-09-16  8:26               ` Shameerali Kolothum Thodi
2021-09-16  8:26               ` Shameerali Kolothum Thodi
2021-09-16 11:16               ` Jon Nettleton
2021-09-16 11:16                 ` Jon Nettleton
2021-09-16 11:16                 ` Jon Nettleton
2021-09-17 11:26                 ` Shameerali Kolothum Thodi
2021-09-17 11:26                   ` Shameerali Kolothum Thodi
2021-09-17 11:26                   ` Shameerali Kolothum Thodi
2021-10-05 10:53                   ` Laurentiu Tudor
2021-10-05 10:53                     ` Laurentiu Tudor
2021-10-05 10:53                     ` Laurentiu Tudor
2021-10-08 12:48   ` Robin Murphy
2021-10-08 12:48     ` Robin Murphy
2021-10-08 12:48     ` Robin Murphy
2021-10-09  7:06     ` Jon Nettleton
2021-10-09  7:06       ` Jon Nettleton
2021-10-09  7:06       ` Jon Nettleton
2021-10-11 14:04       ` Robin Murphy
2021-10-11 14:04         ` Robin Murphy
2021-10-11 14:04         ` Robin Murphy
2021-10-12  8:00         ` Jon Nettleton
2021-10-12  8:00           ` Jon Nettleton
2021-10-12  8:00           ` Jon Nettleton
2021-12-08 12:18           ` Lorenzo Pieralisi
2021-12-08 12:18             ` Lorenzo Pieralisi
2021-12-08 12:18             ` Lorenzo Pieralisi
2021-12-08 13:26             ` Jon Nettleton
2021-12-08 13:26               ` Jon Nettleton
2021-12-08 13:26               ` Jon Nettleton
2021-12-08 14:37               ` Robin Murphy
2021-12-08 14:37                 ` Robin Murphy
2021-12-08 14:37                 ` Robin Murphy
2021-12-08 15:11                 ` Jon Nettleton
2021-12-08 15:11                   ` Jon Nettleton
2021-12-08 15:11                   ` Jon Nettleton
2021-10-11  5:59     ` Shameerali Kolothum Thodi
2021-10-11  5:59       ` Shameerali Kolothum Thodi
2021-10-11  5:59       ` Shameerali Kolothum Thodi
2021-08-05  8:07 ` [PATCH v7 3/9] iommu/dma: Introduce generic helper to retrieve RMR info Shameer Kolothum
2021-08-05  8:07   ` Shameer Kolothum
2021-08-05  8:07   ` Shameer Kolothum
2021-10-08 13:03   ` Robin Murphy
2021-10-08 13:03     ` Robin Murphy
2021-10-08 13:03     ` Robin Murphy
2021-10-11  5:51     ` Shameerali Kolothum Thodi
2021-10-11  5:51       ` Shameerali Kolothum Thodi
2021-10-11  5:51       ` Shameerali Kolothum Thodi
2021-08-05  8:07 ` [PATCH v7 4/9] ACPI/IORT: Add a helper to retrieve RMR memory regions Shameer Kolothum
2021-08-05  8:07   ` Shameer Kolothum
2021-08-05  8:07   ` Shameer Kolothum
2021-08-05 15:43   ` Lorenzo Pieralisi
2021-08-05 15:43     ` Lorenzo Pieralisi
2021-08-05 15:43     ` Lorenzo Pieralisi
2021-08-05  8:07 ` [PATCH v7 5/9] iommu/arm-smmu-v3: Introduce strtab init helper Shameer Kolothum
2021-08-05  8:07   ` Shameer Kolothum
2021-08-05  8:07   ` Shameer Kolothum
2021-08-05  8:07 ` [PATCH v7 6/9] iommu/arm-smmu-v3: Refactor arm_smmu_init_bypass_stes() to force bypass Shameer Kolothum
2021-08-05  8:07   ` Shameer Kolothum
2021-08-05  8:07   ` Shameer Kolothum
2021-08-05  8:07 ` [PATCH v7 7/9] iommu/arm-smmu-v3: Get associated RMR info and install bypass STE Shameer Kolothum
2021-08-05  8:07   ` Shameer Kolothum
2021-08-05  8:07   ` Shameer Kolothum
2021-08-05  8:07 ` [PATCH v7 8/9] iommu/arm-smmu: Get associated RMR info and install bypass SMR Shameer Kolothum
2021-08-05  8:07   ` Shameer Kolothum
2021-08-05  8:07   ` Shameer Kolothum
2021-08-05  8:07 ` [PATCH v7 9/9] iommu/dma: Reserve any RMR regions associated with a dev Shameer Kolothum
2021-08-05  8:07   ` Shameer Kolothum
2021-08-05  8:07   ` Shameer Kolothum
2021-10-08 13:09   ` Robin Murphy
2021-10-08 13:09     ` Robin Murphy
2021-10-08 13:09     ` Robin Murphy
2021-10-09  7:07     ` Jon Nettleton
2021-10-09  7:07       ` Jon Nettleton
2021-10-09  7:07       ` Jon Nettleton
2021-10-11 15:00       ` Robin Murphy
2021-10-11 15:00         ` Robin Murphy
2021-10-11 15:00         ` Robin Murphy
2021-10-11 15:42         ` Shameerali Kolothum Thodi
2021-10-11 15:42           ` Shameerali Kolothum Thodi
2021-10-11 15:42           ` Shameerali Kolothum Thodi
2021-08-05 13:22 ` [PATCH v7 0/9] ACPI/IORT: Support for IORT RMR node Ard Biesheuvel
2021-08-05 13:22   ` Ard Biesheuvel
2021-08-05 13:22   ` Ard Biesheuvel
2021-08-05 13:35   ` Shameerali Kolothum Thodi
2021-08-05 13:35     ` Shameerali Kolothum Thodi
2021-08-05 13:35     ` Shameerali Kolothum Thodi
2021-08-05 14:09     ` Ard Biesheuvel
2021-08-05 14:09       ` Ard Biesheuvel
2021-08-05 14:09       ` Ard Biesheuvel
2021-08-31  5:06       ` Jon Nettleton
2021-08-31  5:06         ` Jon Nettleton
2021-08-31  5:06         ` Jon Nettleton
2021-09-30  9:47 ` Eric Auger
2021-09-30  9:47   ` Eric Auger
2021-09-30  9:47   ` Eric Auger
2021-09-30 10:50   ` Shameerali Kolothum Thodi
2021-09-30 10:50     ` Shameerali Kolothum Thodi
2021-09-30 10:50     ` Shameerali Kolothum Thodi
2022-01-25 13:00 ` Shameerali Kolothum Thodi via iommu
2022-01-25 13:00   ` Shameerali Kolothum Thodi
2022-01-25 13:00   ` Shameerali Kolothum Thodi
2022-01-25 19:30   ` Robin Murphy
2022-01-25 19:30     ` Robin Murphy
2022-01-25 19:30     ` Robin Murphy

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=CABdtJHuhpnASw8NQb7dRo42Z5NqOzvtvjoyndsJ2jd+Qvsq7vQ@mail.gmail.com \
    --to=jon@solid-run.com \
    --cc=Sami.Mujawar@arm.com \
    --cc=eric.auger@redhat.com \
    --cc=guohanjun@huawei.com \
    --cc=iommu@lists.linux-foundation.org \
    --cc=joro@8bytes.org \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linuxarm@huawei.com \
    --cc=lorenzo.pieralisi@arm.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 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.