On 28/09/2019 00:52, Oleksandr Tyshchenko wrote: > сб, 28 сент. 2019 г., 01:50 Stefano Stabellini <sstabell...@kernel.org > <mailto:sstabell...@kernel.org>>: > > On Thu, 26 Sep 2019, Oleksandr wrote: > > On 26.09.19 17:56, Julien Grall wrote: > > > Hi, > > > > Hi Julien > > > > > > > > > > On 9/26/19 12:20 PM, Oleksandr Tyshchenko wrote: > > > > Oleksandr Tyshchenko (8): > > > > iommu/arm: Add iommu_helpers.c file to keep common for > IOMMUs stuff > > > > iommu/arm: Add ability to handle deferred probing request > > > > xen/common: Introduce _xrealloc function > > > > xen/common: Introduce xrealloc_flex_struct() helper macros > > > > iommu/arm: Add lightweight iommu_fwspec support > > > > iommu: Order the headers alphabetically in device_tree.c > > > > iommu/arm: Introduce iommu_add_dt_device API > > > > iommu/arm: Add Renesas IPMMU-VMSA support > > > > > > This series is now merged. > > > > Thank you! > > I just wanted to provide early feedback that this series causes problems > with the legacy mmu-masters binding: > > > This series was developed in a way to add new functionality, but not to > brake existing (legacy bindings). Probably, I missed something > important. iommu_add_dt_device() could return an error (I assume, this > is what you are facing) if the device node in DT contains "iommus" > property (I mean, uses new bindings), but the IOMMU driver doesn't > implement required callbacks yet. Do the device nodes in your DT contain > "iommus" property? And to which domain these devices (in your log) are > going to be assigned (dom0 or other domains?).
Looking at the bindings, I don't think it is legit to have a node using both legacy and generic binding together. If this is what happens, then I would consider it as unsupported. Cheers, -- Julien Grall _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
