Hi Laurent, On Fri, Nov 11, 2016 at 1:08 AM, Laurent Pinchart <laurent.pinch...@ideasonboard.com> wrote: > On Thursday 10 Nov 2016 23:40:54 Greg Kroah-Hartman wrote: >> On Thu, Nov 10, 2016 at 11:04:07PM +0100, Luis R. Rodriguez wrote: >> Don't try to make this more difficult than it is please. DEFER works >> today really really well, and it's really really simple. >> Inter-dependancy of modules and devices connected to each other are two >> different things, be careful about this. > > One issue we don't address today is handling of optional dependencies. A > simple example is an SPI controller that can use a DMA engine or work in PIO > mode. At probe time the driver will request a DMA channel if the platform > (ACPI, DT, platform data) specifies that DMA is available. This can fail for > various reasons, one of them being that the DMA engine driver hasn't probed > the DMA device yet. In that case the SPI controller driver will continue in > PIO mode, ignoring the DMA engine that will later be probed. We can't defer > probing of the SPI controller as the DMA engine driver might never get loaded, > which would result in the SPI controller probe being deferred forever. > > One solution for this type of dependency issue would be to notify the SPI > controller driver after probe that the DMA channel is now available. I'd like > to avoid that though, as it would drastically increase the complexity of lots > of drivers and create lots of race conditions.
Alternatively, the driver can request optional DMA resources at open time instead of at probe time. E.g. sh_sci does that in its uart_ops.startup() callback. Regardless of that, DMA can fail temporarily for other reasons (e.g. running out of channels). Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds