| Message ID | 20220615101044.1972-1-shameerali.kolothum.thodi@huawei.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | ACPI/IORT: Support for IORT RMR node | expand |
On 15/06/2022 11:10, Shameer Kolothum wrote: > Hi > > v12 --> v13 > -No changes. Rebased to 5.19-rc1. > -Picked up tags received from Laurentiu, Hanjun and Will. Thanks!. You've already got my Tested-by tags, but just to confirm I gave this a spin and it works fine. Thanks, Steve > > Thanks, > Shameer > > From old: > We have faced issues with 3408iMR RAID controller cards which > fail to boot when SMMU is enabled. This is because these > controllers make use of host memory for various caching related > purposes and when SMMU is enabled the iMR firmware fails to > access these memory regions as there is no mapping for them. > IORT RMR provides a way for UEFI to describe and report these > memory regions so that the kernel can make a unity mapping for > these in SMMU. > > Change History: > > v11 --> v12 > -Minor fix in patch #4 to address the issue reported by the kernel test robot. > -Added R-by tags by Christoph(patch #1) and Lorenzo(patch #4). > -Added T-by from Steve to all relevant patches. Many thanks!. > > v10 --> v11 > -Addressed Christoph's comments. We now have a callback to > struct iommu_resv_region to free all related memory and also dropped > the FW specific union and now has a container struct iommu_iort_rmr_data. > See patches #1 & #4 > -Added R-by from Christoph. > -Dropped R-by from Lorenzo for patches #4 & #5 due to the above changes. > -Also dropped T-by from Steve and Laurentiu. Many thanks for your test > efforts. I have done basic sanity testing on my platform but please > do it again at your end. > > v9 --> v10 > - Dropped patch #1 ("Add temporary RMR node flag definitions") since > the ACPICA header updates patch is now in the mailing list > - Based on the suggestion from Christoph, introduced a > resv_region_free_fw_data() callback in struct iommu_resv_region and > used that to free RMR specific memory allocations. > > v8 --> v9 > - Adressed comments from Robin on interfaces. > - Addressed comments from Lorenzo. > > v7 --> v8 > - Patch #1 has temp definitions for RMR related changes till > the ACPICA header changes are part of kernel. > - No early parsing of RMR node info and is only parsed at the > time of use. > - Changes to the RMR get/put API format compared to the > previous version. > - Support for RMR descriptor shared by multiple stream IDs. > > v6 --> v7 > -fix pointed out by Steve to the SMMUv2 SMR bypass install in patch #8. > > v5 --> v6 > - Addressed comments from Robin & Lorenzo. > : Moved iort_parse_rmr() to acpi_iort_init() from > iort_init_platform_devices(). > : Removed use of struct iort_rmr_entry during the initial > parse. Using struct iommu_resv_region instead. > : Report RMR address alignment and overlap errors, but continue. > : Reworked arm_smmu_init_bypass_stes() (patch # 6). > - Updated SMMUv2 bypass SMR code. Thanks to Jon N (patch #8). > - Set IOMMU protection flags(IOMMU_CACHE, IOMMU_MMIO) based > on Type of RMR region. Suggested by Jon N. > > v4 --> v5 > -Added a fw_data union to struct iommu_resv_region and removed > struct iommu_rmr (Based on comments from Joerg/Robin). > -Added iommu_put_rmrs() to release mem. > -Thanks to Steve for verifying on SMMUv2, but not added the Tested-by > yet because of the above changes. > > v3 -->v4 > -Included the SMMUv2 SMR bypass install changes suggested by > Steve(patch #7) > -As per Robin's comments, RMR reserve implementation is now > more generic (patch #8) and dropped v3 patches 8 and 10. > -Rebase to 5.13-rc1 > > RFC v2 --> v3 > -Dropped RFC tag as the ACPICA header changes are now ready to be > part of 5.13[0]. But this series still has a dependency on that patch. > -Added IORT E.b related changes(node flags, _DSM function 5 checks for > PCIe). > -Changed RMR to stream id mapping from M:N to M:1 as per the spec and > discussion here[1]. > -Last two patches add support for SMMUv2(Thanks to Jon Nettleton!) > > Jon Nettleton (1): > iommu/arm-smmu: Get associated RMR info and install bypass SMR > > Shameer Kolothum (8): > iommu: Introduce a callback to struct iommu_resv_region > ACPI/IORT: Make iort_iommu_msi_get_resv_regions() return void > ACPI/IORT: Provide a generic helper to retrieve reserve regions > ACPI/IORT: Add support to retrieve IORT RMR reserved regions > ACPI/IORT: Add a helper to retrieve RMR info directly > iommu/arm-smmu-v3: Introduce strtab init helper > iommu/arm-smmu-v3: Refactor arm_smmu_init_bypass_stes() to force > bypass > iommu/arm-smmu-v3: Get associated RMR info and install bypass STE > > drivers/acpi/arm64/iort.c | 360 ++++++++++++++++++-- > drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c | 78 ++++- > drivers/iommu/arm/arm-smmu/arm-smmu.c | 52 +++ > drivers/iommu/dma-iommu.c | 2 +- > drivers/iommu/iommu.c | 16 +- > include/linux/acpi_iort.h | 14 +- > include/linux/iommu.h | 10 + > 7 files changed, 486 insertions(+), 46 deletions(-) >
> -----Original Message----- > From: Steven Price [mailto:steven.price@arm.com] > Sent: 17 June 2022 13:42 > 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: Linuxarm <linuxarm@huawei.com>; lorenzo.pieralisi@arm.com; > joro@8bytes.org; robin.murphy@arm.com; will@kernel.org; wanghuiqiang > <wanghuiqiang@huawei.com>; Guohanjun (Hanjun Guo) > <guohanjun@huawei.com>; Sami.Mujawar@arm.com; jon@solid-run.com; > eric.auger@redhat.com; laurentiu.tudor@nxp.com; hch@infradead.org > Subject: Re: [PATCH v13 0/9] ACPI/IORT: Support for IORT RMR node > > On 15/06/2022 11:10, Shameer Kolothum wrote: > > Hi > > > > v12 --> v13 > > -No changes. Rebased to 5.19-rc1. > > -Picked up tags received from Laurentiu, Hanjun and Will. Thanks!. > > You've already got my Tested-by tags, but just to confirm I gave this a > spin and it works fine. Thanks Steve. I think the series is now in a good shape to be merged. Hi Will/Robin, Appreciate, if you could please take a look at the remaining SMMU related patches(7-9) and provide your approval? Thanks, Shameer > > Thanks, > > Steve > > > > > Thanks, > > Shameer > > > > From old: > > We have faced issues with 3408iMR RAID controller cards which > > fail to boot when SMMU is enabled. This is because these > > controllers make use of host memory for various caching related > > purposes and when SMMU is enabled the iMR firmware fails to > > access these memory regions as there is no mapping for them. > > IORT RMR provides a way for UEFI to describe and report these > > memory regions so that the kernel can make a unity mapping for > > these in SMMU. > > > > Change History: > > > > v11 --> v12 > > -Minor fix in patch #4 to address the issue reported by the kernel test > robot. > > -Added R-by tags by Christoph(patch #1) and Lorenzo(patch #4). > > -Added T-by from Steve to all relevant patches. Many thanks!. > > > > v10 --> v11 > > -Addressed Christoph's comments. We now have a callback to > > struct iommu_resv_region to free all related memory and also dropped > > the FW specific union and now has a container struct > iommu_iort_rmr_data. > > See patches #1 & #4 > > -Added R-by from Christoph. > > -Dropped R-by from Lorenzo for patches #4 & #5 due to the above > changes. > > -Also dropped T-by from Steve and Laurentiu. Many thanks for your test > > efforts. I have done basic sanity testing on my platform but please > > do it again at your end. > > > > v9 --> v10 > > - Dropped patch #1 ("Add temporary RMR node flag definitions") since > > the ACPICA header updates patch is now in the mailing list > > - Based on the suggestion from Christoph, introduced a > > resv_region_free_fw_data() callback in struct iommu_resv_region and > > used that to free RMR specific memory allocations. > > > > v8 --> v9 > > - Adressed comments from Robin on interfaces. > > - Addressed comments from Lorenzo. > > > > v7 --> v8 > > - Patch #1 has temp definitions for RMR related changes till > > the ACPICA header changes are part of kernel. > > - No early parsing of RMR node info and is only parsed at the > > time of use. > > - Changes to the RMR get/put API format compared to the > > previous version. > > - Support for RMR descriptor shared by multiple stream IDs. > > > > v6 --> v7 > > -fix pointed out by Steve to the SMMUv2 SMR bypass install in patch #8. > > > > v5 --> v6 > > - Addressed comments from Robin & Lorenzo. > > : Moved iort_parse_rmr() to acpi_iort_init() from > > iort_init_platform_devices(). > > : Removed use of struct iort_rmr_entry during the initial > > parse. Using struct iommu_resv_region instead. > > : Report RMR address alignment and overlap errors, but continue. > > : Reworked arm_smmu_init_bypass_stes() (patch # 6). > > - Updated SMMUv2 bypass SMR code. Thanks to Jon N (patch #8). > > - Set IOMMU protection flags(IOMMU_CACHE, IOMMU_MMIO) based > > on Type of RMR region. Suggested by Jon N. > > > > v4 --> v5 > > -Added a fw_data union to struct iommu_resv_region and removed > > struct iommu_rmr (Based on comments from Joerg/Robin). > > -Added iommu_put_rmrs() to release mem. > > -Thanks to Steve for verifying on SMMUv2, but not added the Tested-by > > yet because of the above changes. > > > > v3 -->v4 > > -Included the SMMUv2 SMR bypass install changes suggested by > > Steve(patch #7) > > -As per Robin's comments, RMR reserve implementation is now > > more generic (patch #8) and dropped v3 patches 8 and 10. > > -Rebase to 5.13-rc1 > > > > RFC v2 --> v3 > > -Dropped RFC tag as the ACPICA header changes are now ready to be > > part of 5.13[0]. But this series still has a dependency on that patch. > > -Added IORT E.b related changes(node flags, _DSM function 5 checks for > > PCIe). > > -Changed RMR to stream id mapping from M:N to M:1 as per the spec > and > > discussion here[1]. > > -Last two patches add support for SMMUv2(Thanks to Jon Nettleton!) > > > > Jon Nettleton (1): > > iommu/arm-smmu: Get associated RMR info and install bypass SMR > > > > Shameer Kolothum (8): > > iommu: Introduce a callback to struct iommu_resv_region > > ACPI/IORT: Make iort_iommu_msi_get_resv_regions() return void > > ACPI/IORT: Provide a generic helper to retrieve reserve regions > > ACPI/IORT: Add support to retrieve IORT RMR reserved regions > > ACPI/IORT: Add a helper to retrieve RMR info directly > > iommu/arm-smmu-v3: Introduce strtab init helper > > iommu/arm-smmu-v3: Refactor arm_smmu_init_bypass_stes() to force > > bypass > > iommu/arm-smmu-v3: Get associated RMR info and install bypass STE > > > > drivers/acpi/arm64/iort.c | 360 > ++++++++++++++++++-- > > drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c | 78 ++++- > > drivers/iommu/arm/arm-smmu/arm-smmu.c | 52 +++ > > drivers/iommu/dma-iommu.c | 2 +- > > drivers/iommu/iommu.c | 16 +- > > include/linux/acpi_iort.h | 14 +- > > include/linux/iommu.h | 10 + > > 7 files changed, 486 insertions(+), 46 deletions(-) > > >
On Fri, 24 Jun 2022, Shameerali Kolothum Thodi wrote: Hi, >> -----Original Message----- >> From: Steven Price [mailto:steven.price@arm.com] >> Sent: 17 June 2022 13:42 >> 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: Linuxarm <linuxarm@huawei.com>; lorenzo.pieralisi@arm.com; >> joro@8bytes.org; robin.murphy@arm.com; will@kernel.org; wanghuiqiang >> <wanghuiqiang@huawei.com>; Guohanjun (Hanjun Guo) >> <guohanjun@huawei.com>; Sami.Mujawar@arm.com; jon@solid-run.com; >> eric.auger@redhat.com; laurentiu.tudor@nxp.com; hch@infradead.org >> Subject: Re: [PATCH v13 0/9] ACPI/IORT: Support for IORT RMR node >> >> On 15/06/2022 11:10, Shameer Kolothum wrote: >>> Hi >>> >>> v12 --> v13 >>> -No changes. Rebased to 5.19-rc1. >>> -Picked up tags received from Laurentiu, Hanjun and Will. Thanks!. >> >> You've already got my Tested-by tags, but just to confirm I gave this a >> spin and it works fine. > > Thanks Steve. > > I think the series is now in a good shape to be merged. > > Hi Will/Robin, > > Appreciate, if you could please take a look at the remaining SMMU related > patches(7-9) and provide your approval? > > Thanks, > Shameer First of all thanks to all of you for keeping this going. I've read through most of this patch series and it doesn't read like the best sunny days. I do understand that there are incentives to get things right; sometimes first make it work, then make it better? Running code often seems a better alternative than wrong words on paper as users don't care about the paper. They only care if their hardware becomes a paperweight because it's not working. I was trying to find diplomatic words but the general problem has become so much bigger than just this change as I am faced with the fact that vendors are talking to give up maintaining Arm/ACPI and go back to FDT exclusively, which I believe would be the wrong but an understandable exit out of a roundabout. For me this Arm/Linux/ACPI problem becomes double-impact, as I am not even a Linux person. And part of what Arm/ACPI was solving was the any OS can just works on Arm hardware; for a while people were hoping it could make FDT the next Flash; it just seems it'll not be because people cannot get fixes or workarounds for real world problems into Linux timely? So a very polite but firm prod towards Cambridge from here as well in the hope that you can make a big change to this world by helping not to miss the next merge window/release leading to way bigger impact. It would be rather sad to close the Arm/ACPI chapter for good but it seems that we may be standing on the verge of it if things do not move quick now and different in the future. It'll certainly need change from all sides but the good things is that at the end of the day we all want to make the world a better place. As I mentioned, I have no stakes in this Linux change. I just care about Arm and ACPI because I saw light and a chance in it and I would love to see it stay. Let's all work together in one direction and make it a brighter future for everyone. Can we? Are you in? May God bless you and your work, Bjoern
On 2022-06-24 16:44, Shameerali Kolothum Thodi via iommu wrote: > > >> -----Original Message----- >> From: Steven Price [mailto:steven.price@arm.com] >> Sent: 17 June 2022 13:42 >> 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: Linuxarm <linuxarm@huawei.com>; lorenzo.pieralisi@arm.com; >> joro@8bytes.org; robin.murphy@arm.com; will@kernel.org; wanghuiqiang >> <wanghuiqiang@huawei.com>; Guohanjun (Hanjun Guo) >> <guohanjun@huawei.com>; Sami.Mujawar@arm.com; jon@solid-run.com; >> eric.auger@redhat.com; laurentiu.tudor@nxp.com; hch@infradead.org >> Subject: Re: [PATCH v13 0/9] ACPI/IORT: Support for IORT RMR node >> >> On 15/06/2022 11:10, Shameer Kolothum wrote: >>> Hi >>> >>> v12 --> v13 >>> -No changes. Rebased to 5.19-rc1. >>> -Picked up tags received from Laurentiu, Hanjun and Will. Thanks!. >> >> You've already got my Tested-by tags, but just to confirm I gave this a >> spin and it works fine. > > Thanks Steve. > > I think the series is now in a good shape to be merged. > > Hi Will/Robin, > > Appreciate, if you could please take a look at the remaining SMMU related > patches(7-9) and provide your approval? I said v12 looked fine, but for the avoidance of doubt, here it is again, as formally as can be: Acked-by: Robin Murphy <robin.murphy@arm.com> Thanks, Robin.
> -----Original Message----- > From: Robin Murphy [mailto:robin.murphy@arm.com] > Sent: 27 June 2022 13:26 > To: Shameerali Kolothum Thodi <shameerali.kolothum.thodi@huawei.com>; > Steven Price <steven.price@arm.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>; > hch@infradead.org; Guohanjun (Hanjun Guo) <guohanjun@huawei.com>; > Sami.Mujawar@arm.com; will@kernel.org; wanghuiqiang > <wanghuiqiang@huawei.com>; lpieralisi@kernel.org > Subject: Re: [PATCH v13 0/9] ACPI/IORT: Support for IORT RMR node > > On 2022-06-24 16:44, Shameerali Kolothum Thodi via iommu wrote: > > > > > >> -----Original Message----- > >> From: Steven Price [mailto:steven.price@arm.com] > >> Sent: 17 June 2022 13:42 > >> 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: Linuxarm <linuxarm@huawei.com>; lorenzo.pieralisi@arm.com; > >> joro@8bytes.org; robin.murphy@arm.com; will@kernel.org; > wanghuiqiang > >> <wanghuiqiang@huawei.com>; Guohanjun (Hanjun Guo) > >> <guohanjun@huawei.com>; Sami.Mujawar@arm.com; > jon@solid-run.com; > >> eric.auger@redhat.com; laurentiu.tudor@nxp.com; hch@infradead.org > >> Subject: Re: [PATCH v13 0/9] ACPI/IORT: Support for IORT RMR node > >> > >> On 15/06/2022 11:10, Shameer Kolothum wrote: > >>> Hi > >>> > >>> v12 --> v13 > >>> -No changes. Rebased to 5.19-rc1. > >>> -Picked up tags received from Laurentiu, Hanjun and Will. Thanks!. > >> > >> You've already got my Tested-by tags, but just to confirm I gave this a > >> spin and it works fine. > > > > Thanks Steve. > > > > I think the series is now in a good shape to be merged. > > > > Hi Will/Robin, > > > > Appreciate, if you could please take a look at the remaining SMMU related > > patches(7-9) and provide your approval? > > I said v12 looked fine, but for the avoidance of doubt, here it is > again, as formally as can be: > > Acked-by: Robin Murphy <robin.murphy@arm.com> Thanks Robin. Hi Joerg, Now that we have all the required acks, could you please pick this series via IOMMU tree? Thanks, Shameer
> -----Original Message----- > From: Shameerali Kolothum Thodi > Sent: 28 June 2022 09:00 > To: 'Robin Murphy' <robin.murphy@arm.com>; joro@8bytes.org; > 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>; > hch@infradead.org; Guohanjun (Hanjun Guo) <guohanjun@huawei.com>; > Sami.Mujawar@arm.com; will@kernel.org; wanghuiqiang > <wanghuiqiang@huawei.com>; lpieralisi@kernel.org; Steven Price > <steven.price@arm.com>; lorenzo.pieralisi@gmail.com > Subject: RE: [PATCH v13 0/9] ACPI/IORT: Support for IORT RMR node > > > Hi Will/Robin, > > > > > > Appreciate, if you could please take a look at the remaining SMMU > > > related > > > patches(7-9) and provide your approval? > > > > I said v12 looked fine, but for the avoidance of doubt, here it is > > again, as formally as can be: > > > > Acked-by: Robin Murphy <robin.murphy@arm.com> > > Thanks Robin. > > Hi Joerg, > > Now that we have all the required acks, could you please pick this series via > IOMMU tree? Hi Will, Since Joerg hasn't replied yet, just wondering could you please take it through ARM SMMU tree if that makes sense? Don't want to miss the 5.20 merge window for this series. Thanks, Shameer
On Tue, Jun 28, 2022 at 07:59:39AM +0000, Shameerali Kolothum Thodi wrote: > Now that we have all the required acks, could you please pick this series via > IOMMU tree? Applied to core branch, thanks.
Hi v12 --> v13 -No changes. Rebased to 5.19-rc1. -Picked up tags received from Laurentiu, Hanjun and Will. Thanks!. Thanks, Shameer From old: We have faced issues with 3408iMR RAID controller cards which fail to boot when SMMU is enabled. This is because these controllers make use of host memory for various caching related purposes and when SMMU is enabled the iMR firmware fails to access these memory regions as there is no mapping for them. IORT RMR provides a way for UEFI to describe and report these memory regions so that the kernel can make a unity mapping for these in SMMU. Change History: v11 --> v12 -Minor fix in patch #4 to address the issue reported by the kernel test robot. -Added R-by tags by Christoph(patch #1) and Lorenzo(patch #4). -Added T-by from Steve to all relevant patches. Many thanks!. v10 --> v11 -Addressed Christoph's comments. We now have a callback to struct iommu_resv_region to free all related memory and also dropped the FW specific union and now has a container struct iommu_iort_rmr_data. See patches #1 & #4 -Added R-by from Christoph. -Dropped R-by from Lorenzo for patches #4 & #5 due to the above changes. -Also dropped T-by from Steve and Laurentiu. Many thanks for your test efforts. I have done basic sanity testing on my platform but please do it again at your end. v9 --> v10 - Dropped patch #1 ("Add temporary RMR node flag definitions") since the ACPICA header updates patch is now in the mailing list - Based on the suggestion from Christoph, introduced a resv_region_free_fw_data() callback in struct iommu_resv_region and used that to free RMR specific memory allocations. v8 --> v9 - Adressed comments from Robin on interfaces. - Addressed comments from Lorenzo. v7 --> v8 - Patch #1 has temp definitions for RMR related changes till the ACPICA header changes are part of kernel. - No early parsing of RMR node info and is only parsed at the time of use. - Changes to the RMR get/put API format compared to the previous version. - Support for RMR descriptor shared by multiple stream IDs. v6 --> v7 -fix pointed out by Steve to the SMMUv2 SMR bypass install in patch #8. v5 --> v6 - Addressed comments from Robin & Lorenzo. : Moved iort_parse_rmr() to acpi_iort_init() from iort_init_platform_devices(). : Removed use of struct iort_rmr_entry during the initial parse. Using struct iommu_resv_region instead. : Report RMR address alignment and overlap errors, but continue. : Reworked arm_smmu_init_bypass_stes() (patch # 6). - Updated SMMUv2 bypass SMR code. Thanks to Jon N (patch #8). - Set IOMMU protection flags(IOMMU_CACHE, IOMMU_MMIO) based on Type of RMR region. Suggested by Jon N. v4 --> v5 -Added a fw_data union to struct iommu_resv_region and removed struct iommu_rmr (Based on comments from Joerg/Robin). -Added iommu_put_rmrs() to release mem. -Thanks to Steve for verifying on SMMUv2, but not added the Tested-by yet because of the above changes. v3 -->v4 -Included the SMMUv2 SMR bypass install changes suggested by Steve(patch #7) -As per Robin's comments, RMR reserve implementation is now more generic (patch #8) and dropped v3 patches 8 and 10. -Rebase to 5.13-rc1 RFC v2 --> v3 -Dropped RFC tag as the ACPICA header changes are now ready to be part of 5.13[0]. But this series still has a dependency on that patch. -Added IORT E.b related changes(node flags, _DSM function 5 checks for PCIe). -Changed RMR to stream id mapping from M:N to M:1 as per the spec and discussion here[1]. -Last two patches add support for SMMUv2(Thanks to Jon Nettleton!) Jon Nettleton (1): iommu/arm-smmu: Get associated RMR info and install bypass SMR Shameer Kolothum (8): iommu: Introduce a callback to struct iommu_resv_region ACPI/IORT: Make iort_iommu_msi_get_resv_regions() return void ACPI/IORT: Provide a generic helper to retrieve reserve regions ACPI/IORT: Add support to retrieve IORT RMR reserved regions ACPI/IORT: Add a helper to retrieve RMR info directly iommu/arm-smmu-v3: Introduce strtab init helper iommu/arm-smmu-v3: Refactor arm_smmu_init_bypass_stes() to force bypass iommu/arm-smmu-v3: Get associated RMR info and install bypass STE drivers/acpi/arm64/iort.c | 360 ++++++++++++++++++-- drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c | 78 ++++- drivers/iommu/arm/arm-smmu/arm-smmu.c | 52 +++ drivers/iommu/dma-iommu.c | 2 +- drivers/iommu/iommu.c | 16 +- include/linux/acpi_iort.h | 14 +- include/linux/iommu.h | 10 + 7 files changed, 486 insertions(+), 46 deletions(-)