On 12/12/2013 12:57 AM, Hiroshi Doyu wrote: > ops->{bound,unbind}_driver() functions are called at > BUS_NOTIFY_{BOUND,UNBIND}_DRIVER respectively. Some explanation re: why the existing {add,remove}_device hooks aren't enough would be useful. I didn't really get that from the current commit description. What actions would an IOMMU driver take in these new callbacks that could not be taken in {add,remove}_device? Surely the IOMMU could set up any internal data structures, AS, or page tables, etc. within add_device, rather than deferring to bound_driver, which presumably happens after the device's probe(), yet the driver might want to make the HW do bus-master accesses within probe(), or at least map stuff into the page table... > This is necessary to control the device population order. IOMMU master > devices depend on an IOMMU device instanciation. IOMMU master devices Is an "IOMMU master device" the device that issues transactions on the bus, which are affected by the IOMMU? The more common term for this is "bus master"; "IOMMU master device" sounds too similar to the "IOMMU" itself. -- To unsubscribe from this list: send the line "unsubscribe linux-tegra" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html