Re: Please revert 5adc55da4a7758021bcc374904b0f8b076508a11 (PCI_MULTITHREAD_PROBE)

[Duncan Sands <duncan.sands@math.u-psud.fr>]

Hi,

> Instead of changing existign probe functionality to be asynchronous, we 
> could *add* a new and asynchronous part to it. For example, we could make 
> the rule for PCI - or other bus - devices be:
> 
>  - the bus will *first* call the "probe()" function synchronously.
> 
>  - after that one has completed, we will call "probe_async()" 
>    asynchronously at some point (it ie might be scheduled immediately 
>    after the "probe()" call, but delayed by some arbitrary issues like 
>    just already having too many asynchronous probes on-going or similar)

the usbatm USB ADSL modem drivers have this functionality.  These drivers
need to load firmware before they become useful.  The natural place to do
this is in the probe() method, but because firmware loading can take quite
some time (10 seconds, or even an infinite amount of time if the firmware
is not available and the timeout has been turned off) and would block the
USB hub thread if done from probe(), it's done in a separate kernel thread.
Clients of usbatm, like the speedtch driver, register themselves with usbatm,
providing a "bind" and a "heavy_init" method.  "bind" is like probe(), while
"heavy_init" is like probe_async().  First bind is called, and if successful
and heavy_init has been defined, then heavy_init is run in its own thread.
If the device is unplugged, usbatm takes care of making sure that the heavy_init
thread has stopped before calling unbind and destroying device related structures.

A bunch of other USB drivers could do with similar functionality for the
same reason (slow probe), and there was some discussion about generalizing
this functionality to the USB layer but I didn't find time to do anything
about it yet.  See http://marc.info/?l=linux-usb-devel&m=116551653026075&w=2

Best wishes,

Duncan.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/