On 10/25/2013 03:11 AM, Thierry Reding wrote: ... > So my proposed solution for the IOMMU case is to treat it the same > as any other resources. Perhaps resource isn't the right word, but > at the core the issue is the same. A device requires the services > of an IOMMU so that it can be put into the correct address space. > If the IOMMU is not available yet it cannot do that, so we simply > return -EPROBE_DEFER and cause the probe to be retried later. Personally, I view deferred probe as being used when one device requires either a resource /or/ a service provided by another, not /just/ when there's a resource dependency. Hence, I think it fits perfectly here. So I agree with Thierry: In other words, I think the solution is for all devices that are affected by an IOMMU to have a property such as: iommu = <&iommu_phandle iommu_specifier>; (and the DT node for the IOMMU will contain e.g. an #iommu-cells property) ... and for the driver to explicitly parse that property, and wait until the driver for iommu_phandle is ready. Exactly the same as any other resource/service dependency. That will solve all the problems. The only downside is that every driver needs to contain code to parse that property. However, I think that's just one function call; the actual implementation of that function can be unified somewhere inside core code in drivers/iommu/. -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
