> -----Original Message----- > From: Steven Price [mailto:steven.pr...@arm.com] > Sent: 21 April 2022 13:59 > To: Shameerali Kolothum Thodi <shameerali.kolothum.th...@huawei.com>; > linux-arm-ker...@lists.infradead.org; linux-a...@vger.kernel.org; > iommu@lists.linux-foundation.org > Cc: Linuxarm <linux...@huawei.com>; lorenzo.pieral...@arm.com; > j...@8bytes.org; robin.mur...@arm.com; w...@kernel.org; wanghuiqiang > <wanghuiqi...@huawei.com>; Guohanjun (Hanjun Guo) > <guohan...@huawei.com>; sami.muja...@arm.com; j...@solid-run.com; > eric.au...@redhat.com; laurentiu.tu...@nxp.com; h...@infradead.org > Subject: Re: [PATCH v10 0/9] ACPI/IORT: Support for IORT RMR node > > On 20/04/2022 17:48, Shameer Kolothum wrote: > > Hi > > > > v9 --> v10 > > - Dropped patch #1 ("Add temporary RMR node flag definitions") since > > the ACPICA header updates patch is now in the mailing list[1] > > - 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. > > > > Though there is a small change from v9 with respect to how we free up > > the FW specific data, I have taken the liberty to pick up the R-by and > > T-by tags from Lorenzo, Steve and Laurentiu. But please do take a look > > again and let me know. > > I've given this a go and it works fine on my Juno setup. So do keep my > T-by tag. Many thanks for that. > Sami has been kind enough to give me an updated firmware which also > fixes the RMR node in the IORT. Although as mentioned before the details > of the RMR node are currently being ignored so this doesn't change the > functionality but silences the warning. > > My concern is that with the RMR region effectively ignored we may see > more broken firmware, and while a length of zero produces a warning, an > otherwise incorrect length will currently "silently work" but mean that > any future tightening would cause problems. For example if the SMMU > driver were to recreate the mappings to only cover the region specified > in the RMR it may not be large enough if the RMR base/length are not > correct. Not sure how we can further validate the RMR if the firmware provides an incorrect one. I see your point of future tightening causing problems with broken firmware. But then it is indeed a "broken firmware"... It's up to the maintainers as to whether they see this as a > problem or not. Hi Robin, Any thoughts on this? Thanks, Shameer _______________________________________________ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
RE: [PATCH v10 0/9] ACPI/IORT: Support for IORT RMR node
Shameerali Kolothum Thodi via iommu Thu, 21 Apr 2022 07:43:27 -0700
- Re: [PATCH v10 3/9] ACPI/IORT: Pr... Christoph Hellwig
- [PATCH v10 4/9] ACPI/IORT: Add support... Shameer Kolothum via iommu
- Re: [PATCH v10 4/9] ACPI/IORT: Ad... Christoph Hellwig
- RE: [PATCH v10 4/9] ACPI/IORT... Shameerali Kolothum Thodi via iommu
- [PATCH v10 5/9] ACPI/IORT: Add a helpe... Shameer Kolothum via iommu
- [PATCH v10 6/9] iommu/arm-smmu-v3: Int... Shameer Kolothum via iommu
- [PATCH v10 7/9] iommu/arm-smmu-v3: Ref... Shameer Kolothum via iommu
- [PATCH v10 8/9] iommu/arm-smmu-v3: Get... Shameer Kolothum via iommu
- [PATCH v10 9/9] iommu/arm-smmu: Get as... Shameer Kolothum via iommu
- Re: [PATCH v10 0/9] ACPI/IORT: Support... Steven Price
- RE: [PATCH v10 0/9] ACPI/IORT: Su... Shameerali Kolothum Thodi via iommu
- Re: [PATCH v10 0/9] ACPI/IORT... Robin Murphy