On Thu, Jan 05, 2017 at 08:21:53PM +0530, Sricharan wrote:

Hi,

[...]

quoted

quoted

quoted

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(...)

quoted

	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?

quoted

		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.

Ok, I put together a branch where you can find your original series
plus some ACPI patches for you to test and use:

git://git.kernel.org/pub/scm/linux/kernel/git/lpieralisi/linux.git iommu/probe-deferral

Feel free to post the additional patches I added along with your series
(that from what I gather you have reworked already) and please both have a
look if the deferral mechanism I put in place in ACPI makes sense to you.

Please CC linux-acpi upon posting, if you need help shout.

Lorenzo