Paul Mundt wrote: > In some cases that might be valid, but there are many cases where drivers > can reconfigure their capability sets based on which GPIOs are and aren't > available. Just because a pin isn't available doesn't make it a > show-stopper for the probe path.. > Understood. I just tweaked my kernel to run all probe()s in their own kthreads. The results were a mixed bag, as expected. On the one hand, it's pretty cool to see everything running in parallel! On the other hand, I can see now yet another big reason why a probe free-for-all won't work. Busses are also devices, so there are plenty of places where a device for a particular bus type won't be able to probe because the target bus simply doesn't exist yet. That's yet another dependency that I hadn't thought about. Were I to rewrite Linux :), I would make probing parallel from the beginning. But I think I'm going to have to settle for now with kthreading my probes that might want to sleep, and adding a wait queue to gpio_request() and a few others. It ain't perfect, but it is achieveable. *sigh* b.g. -- Bill Gatliff bgat@xxxxxxxxxxxxxxx -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
