I'll hold back on comments about some of these till later, but several of them look good.
- Dave On Monday 12 June 2006 12:15 pm, Alan Stern wrote: > 1. Change the disconnect checking in devio.c (the usbfs code) so > that it will detect cases where the device has been unregistered > from usbfs, even if the device is still connected. Although this > can't happen now, it will be able to occur after patch 4. The usbfs model is still problematic, but fixing it will take time. Especially given a need to let applications keep working! > 2. Fix usb-skeleton so that it won't try to submit URBs after its > disconnect method has returned. It's quite likely that there > are drivers based on usb-skeleton in need of the same fix, but > I don't know which ones they are. I remember discussions on that topic a few years back ... a few drivers got fixed, evidently not this significant one. I guess I have a hard time taking any driver seriously that doesn't have even a mutex to synchronize threads which may be concurrently issuing calls like read(), write(), disconnect(), and suspend(). > 3. Move some driver-related code from usb.c to driver.c. These > routines (concerned with uevent generation and claiming/releasing > interfaces as well as suspend/resume handling) should have gone > into driver.c when it was first split off, but they got left > behind somehow. So Documentation/DocBook/usb.tmpl needs an update too, right? To include all these functions. You can even add things like section headers to better explain how the parts of those APIs fit together. > 5. Rename usb_suspend_device to usb_port_suspend (and likewise for > _resume). Originally I did this because I wanted to name a > different routine "usb_suspend_device". In the end I chose a > separate name, but it still seemed worthwhile to keep the > "usb_port_suspend" name, for two reasons: The routine isn't any > longer a main entry into the suspend pathway, and it isn't much > more than a wrapper around hub_port_suspend. And in fact that's the best way to view it anyway: it suspends a single point-to-point USB link, a.k.a. "port". A model which maps that directly to the hardware capabilities -- in this case the power supply, control, and data links are already wrapped up in one neat bundle -- is going to be hard to goof up over time. :) > 6. Split the core suspend and resume routines into two pieces, one > for handling USB devices and the other for handling USB > interfaces. This is cleaner than doing them both in one routine. Agreed. I'm glad usbcore is now in good enough shape that this kind of split can now be done! > 7. Remove the recursion in suspend and resume. This has been overdue > for some time. It won't affect system suspends, since the PM core > does its own recursion through the entire device tree. And since the suspend path recursion was pretty much all removed sometime last fall. When other changes broke the resume path updates, I decided they weren't ready to submit. _______________________________________________ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
