[PATCH 02/10] iommu/of: Prepare for deferred IOMMU configuration

[Sricharan]

Hi,

[...]

>>>
>>> With the thinking of taking this series through, would it be fine if i
>>> cleanup the pci configure hanging outside and push it in to
>>> of/acpi_iommu configure respectively ? This time with all neeeded for
>>> ACPI added as well.  Also on the last post of V4, Lorenzo commented
>>> that it worked for him, although still the of_match_node equivalent in
>>> ACPI has to be added. If i can get that, then i will add that as well
>>> to make this complete.
>>
>> Question: I had a look into this and instead of fiddling about with the
>> linker script entries in ACPI (ie IORT_ACPI_DECLARE - which I hope this
>> patchset would help remove entirely), I think that the only check we
>> need in IORT is, depending on what type of SMMU a given device is
>> connected to, to check if the respective SMMU driver is compiled in the
>> kernel and it will be probed, _eventually_.
>>
>> As Robin said, by the time a device is probed the respective SMMU
>> devices are already created and registered with IORT kernel code or
>> they will never be, so to understand if we should defer probing
>> SMMU device creation is _not_ really a problem in ACPI.
>>
>> To check if a SMMU driver is enabled, do we really need a linker
>> table ?
>>
>> Would not a check based on eg:
>>
>> /**
>>  * @type: IOMMU IORT node type of the IOMMU a device is connected to
>>  */
>> static bool iort_iommu_driver_enabled(u8 type)
>> {
>> 	switch (type) {
>> 	case ACPI_IORT_SMMU_V3:
>> 		return IS_ENABLED(CONFIG_ARM_SMMU_V3);
>
>IS_BUILTIN(...)
>
>> 	case ACPI_IORT_SMMU:
>> 		return IS_ENABLED(CONFIG_ARM_SMMU);
>> 	default:
>> 		pr_warn("Unknown IORT SMMU type\n");
>
>Might displaying the actual value be helfpul for debugging a broken IORT
>table?
>
>> 		return false;
>> 	}
>> }
>>
>> be sufficient (it is a bit gross, agreed, but it is to understand if
>> that's all we need) ? Is there anything I am missing ?
>>
>> Let me know, I will put together a patch for you I really do not
>> want to block your series for this trivial niggle.
>
>Other than that, though, I like it :) IORT has a small, strictly
>bounded, set of supported devices, so I really don't see the need to go
>overboard putting it on parity with DT when something this neat and
>simple will suffice.
>

Ok sure, looks correct for me as well in whole of the context here.

Regards,
 Sricharan