Is it true that the various callbacks emanating from hcd-pci.c have guaranteed mutual exclusion?
Not entirely. Ones initiated by "rmmod" or power management have to go right in, no matter what else is going on. If an HCD needs mutual exclusion for any purpose, it must handle that itself.
When the driver detects that the controller has stopped functioning (like those pesky VIA units are prone to do) should it call usb_hc_died()?
That'd probably be a good idea.
If yes, is there some notion that in the future hcd_panic() will eventually try to re-initialize the controller, up to some fixed number of retries (or retries within some fixed period of time)?
It remains a notion. I'm not planning to implement it myself.
In general the hcd_panic() path needs to integrate with khubd so that cleanup works better ... doing it from keventd can cause deadlocks with driver disconnect() callbacks that need to flush work queues! And I've been thinking that such "restart this controller" policy choices probably should be triggered from userspace/sysfs. (Along with "shut down the controller"; in general, device management should be explicit, not just a side-effect of "modprobe". Among other things, not everyone uses modular builds...)
Who really owns hcd->state? Some of the routines in hcd-pci.c set it while others expect the HCD to set it. It's not protected by any lock. Doesn't this need to be sorted out?
Maybe, if there's a particular problem. Mostly the HCD glue changes that to reflect HCD initialization or shutdown.
The HCD changing it to RUNNING the instant before the hardware is actually turned on. The HCD glue can't make that particular transition, since usbcore _does_ end up needing to do things almost immediately (IRQs fire etc); things which would be errors on non-RUNNING hardware. And that's before calls could return to hcd-pci.c ...
It certainly wouldn't hurt to eyeball that logic; I notice the OMAP and SA1111 code has some old logic that should maybe removed now, for example. And of course, UHCI is not trying to use it at all!
That state model isn't as clean as it might be, but so far that hasn't been an issue ... and it was better than what went before, where there was no notion of what sorts of operations made sense. (Queuing urbs to disabled HCDs, for example, never makes sense.)
- Dave
------------------------------------------------------- SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and deploy apps & Web services for Linux with a free DVD software kit from IBM. Click Now! http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
