On Thu, Feb 6, 2020 at 2:32 AM John Garry <john.garry@xxxxxxxxxx> wrote:
Hi guys,
Sorry it took a while to get back.
According to "Limitations" section @
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/driver-api/device_link.rst#n110,
for a managed link, lack of the supplier driver may cause indefinite
delay in probing of the consumer. Is there any way around this?
Currently, no. There's no way to guarantee ordering AND ignore
supplier failures.
So I just want the probe order attempt of the supplier and consumer to
be guaranteed, but the supplier probe may not be successful, i.e. does
not actually bind.
In my case, I would like to use device_link_add(supplier, consumer,
DL_FLAG_AUTOPROBE_CONSUMER), but I find the supplier probe may fail (and
not due to -EPROBE_DEFER), and my consumer remains in limbo.
The requirements seem to contradict each other. If you depend on the
supplier, how can you probe the consumer if the supplier fails?
You may ask my I want this ordering at all - it is because in
really_probe(), we do the device DMA configure before the actual device
driver probe, and I just need that ordering to be ensured between devices.
I'm assuming the supplier in your case is the "dma device" (is it an
iommu?)?
supplier? I'd think something like a DMA would be fundamental?
Why can't this logic be handled in your consumer driver instead of
using device links?
-EPROBE_DEFER if the dma ops are not set up correctly until some point
after which (after late_initcall?) the consumer will continue probing
without returning -EPROBE_DEFER even if the supplier isn't there/dma
ops aren't set up? >
Can you give a more concrete example of your devices? Or why the
suggestion above might not work?