On Sun, 22 Feb 2004, David Brownell wrote: > Alan Stern wrote: > >> If an HCD needs > >>mutual exclusion for any purpose, it must handle that itself. > > > > > > Does the PCI layer at least guarantee that it won't call through any of > > the other routines while either probe or remove is running? > > Nope. It's common to start getting IRQs during probe, for example. > Or in the case of the HCD glue, "start". Why would you want such > a guarantee? With a lock in your code, it should work either way.
All right, aside from IRQ callbacks. For instance, is it guaranteed that probe and remove will never run simultaneously? Is it guaranteed that neither suspend nor resume will be called during either probe or remove? Is it guaranteed that suspend and resume will not overlap? These are all things I would expect, much as usbdev->serialize enforces similar guarantees for USB device drivers. I can't recall at the moment why I wanted such a guarantee, but there must have been a good reason... > >> 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...) > > > > > > One approach might be to have a "running" sysfs attribute (0 or 1), plus a > > max_restarts attribute (max number of times the controller will be > > automatically restarted within a 1-minute interval). > > Are you sure "running" is just two values? Seems to me that > suspend/resume adds at least two more states... Well, maybe one more state: stopped, suspended, and running. I'm not sure there's a significant difference between stopped and suspended, though. The only difference I can think of lies in the response to remote wakeup requests. Maybe that's enough. > Such a "max_restarts" parameter could easily be managed in the > shared part of HCD infrastructure, with a timer. But it could > also be done entirely in userspace, given some on/off mechanism > and something monitoring root hub removal through hotplug. > > Automatic restarts don't appeal to me though. For OHCI and > EHCI, the "controller died" cases have been almost exclusively > software bugs. (Which have been vanishing over time...) I sure would like to reach that point with UHCI! > On the other hand, an even simpler and more general-purpose > mechanism here would be if sysfs were to support binding and > unbinding of particular drivers to particular devices. > (There'd need to be a notion of a "null" binding, maybe a > NOP driver, so hotplugging wouldn't automagically re-bind.) > > When root hub is removed, nullify the binding of the HCD to > that hardware ... then re-bind would do the complete driver > initialization, whether or not it's a modular build. > > That mechanism could be used for other things too. Elegant. Though I don't think it would simplify the driver code at all. Alan STern ------------------------------------------------------- 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
