On Tue, Oct 14, 2014 at 06:01:58PM +0300, Laurent Pinchart wrote: > Hi Thierry, > > On Tuesday 14 October 2014 15:37:59 Thierry Reding wrote: > > On Tue, Oct 14, 2014 at 03:20:46PM +0200, Arnd Bergmann wrote: > > > On Tuesday 14 October 2014 16:07:38 Laurent Pinchart wrote: > > >> On Tuesday 23 September 2014 09:44:25 Arnd Bergmann wrote: > > >>> On Tuesday 23 September 2014 09:02:39 Thierry Reding wrote: > > >>>>> I see two problems with using deferred probing here: > > >>>>> > > >>>>> - we don't actually need to defer the probing but the binding to > > >>>>> the driver when no dma ops are set, but it seems silly to even > > >>>>> create the device before we can find out which ops it should use. > > >>>> > > >>>> What does device creation have to do with anything? Surely a device > > >>>> won't need IOMMU services before the device is bound to a driver. > > >>> > > >>> The problem is that the driver will start using the IOMMU as soon > > >>> as it calls dma_map_*, but that happens at runtime, not necessarily > > >>> during the probe function. > > >>> > > >>> So we can get into the weird situation that probe() returns success, > > >>> but then you can't use the device yet because you don't know whether > > >>> it is supposed to use an IOMMU or not. > > >> > > >> If we want IOMMU devices to be supported by common device drivers we > > >> need to defer probing of the master devices, there's no doubt about > > >> that. Earlier approaches that hooked up into the device core code were > > >> rejected, but it should be possible to use bus notifiers to achieve the > > >> same result (with the drawback of having to register one notifier per > > >> bus). The BUS_NOTIFY_BIND_DRIVER notifier can then just return - > > >> EPROBE_DEFER when a iommus property is available and points to an IOMMU > > >> not registered yet. I'm not saying we have to do this, but I believe that > > >> at least from a technical point of view it could be done. > > > > > > I think that fundamentally speaking, relying on notifiers for something > > > like this is very problematic, both in terms of maintainability and > > > reliability. We should really try to get the notifiers out of the iommu > > > handling, not put more of them in. > > > > Agreed. Also last time I checked the driver core simply ignored the > > return value from notifiers, therefore this wouldn't work without > > changing the core either. > > > > Still, I agree with Laurent that we really should be relying on probe > > deferral for probe ordering. > > *If* we decide to support IOMMUs with real devices ;-) > > I don't have a strong opinion on the subject. I initially thought it would be > a shame not to be able to use devres, until realizing that binding to a DT > node instead of a device meant that no unbind can ever occur. Loosing dev_* > support is also an annoyance though.
Binding to a DT node then also means that you can't build the driver as a module. And in particular for multiplatform kernels this is going to be a problem eventually. Thierry
pgpXaYiR0yqh9.pgp
Description: PGP signature
_______________________________________________ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
