Hi Laurent, On Mon, Feb 27, 2012 at 12:47 AM, Laurent Pinchart <laurent.pinchart@xxxxxxxxxxxxxxxx> wrote: > I'm asking about the probe deferral mechanism. The omap3-isp driver will still > call iommu_attach_device() in its probe function. What will happen then ? Will > it return an error ? On what basis will it do so ? Yes, iommu_attach_device() will fail, and omap3isp's probe function will then need to return -EAGAIN to request that its probe function will be invoked again later on. > That's what the comment in the Makefile is for ;-) I don't think it's a > perfect solution either, but it avoids playing with the various initcalls. The > OMAP3 IOMMU isn't a subsystem, subsys_initcall() looks a bit like an API abuse > to me. Yes, it's dirty. But it's explicit and consistent across build system changes (without imposing anything on the build system). We do it all the time with other subsystems. We don't like it, but luckily Grant came up with the deferred probing mechanism, which will fix this all very nicely. > Are drivers supposed to call iommu_attach_device() in their probe() function > or later on ? If you can defer attaching to a later point, most commonly to a point where the device is opened by the user, it's better - less power will be consumed. Thanks, Ohad. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
