Re: [Bug 43247] O2 micro SD/MMC+1394 controller: 1394 device can't work (Register access failure)

[Bjorn Helgaas <bhelgaas@google.com>]

> Jennifer and the other reporters of the issue most certainly all used
> modular kernels, i.e. got the drivers loaded by udev.
>
> module_init() doesn't matter, but
>   - .probe(),
>   - .resume()
> do.  So as you say, if the drivers were statically linked, then at least
> .probe() would be performed serially, one PCI device after another,
> right?  But AFAIK .resume() would still be performed in parallel by a
> pool of kernel threads in current kernels.

OK, I see.  When both drivers are loaded near the same time via udev,
the firewire driver doesn't work correctly.  I don't know of anything
that serializes driver registration from dynamically loaded modules.

I wouldn't bother with the resume issue until after the load-time
issue is resolved because suspend/resume makes things harder to debug.
 You might be able to try loading/unloading the modules in a loop to
reproduce the issue in a single boot.

> From what I can tell, there is no driver bug but an unfortunate interaction
> between parts of a combo controller which in theory should functionally be
> totally unrelated.

That's plausible.  But I can't think of anything useful the PCI core
can do here.  If you can identify a hardware issue in the device, it's
possible you could write a quirk to work around it.  But after the
driver has called pci_enable_device() (the last point at which quirks
are applied), the PCI core is pretty much out of the picture.

Maybe something could be added to one or both drivers to look for
these devices and try deal with them?  I'm afraid I don't have any
good ideas here.