In an off-list discussion, David Brownell and I considered the possibility of re-targeting the "halted" member of struct usb_device. Right now it really isn't used for much of anything at all. The UHCI driver sets a bit to indicate receipt of a STALL token for a bulk or interrupt endpoint, and the various endpoint_disable() routines also set the appropriate bit. usb_clear_halt() clears the bit, and usb_submit_urb() checks that the bit is clear before accepting a submission. Apparently the original intent was to mark endpoints that are halted, so as to avoid sending useless URBs.
But that's not such a good idea. Nothing prevents a device from un-halting an endpoint on its own initiative, without informing the host. Some device controllers actually do that. Also, the current practice of using the same bit to indicate that an endpoint is halted and to indicate that the core doesn't want to use it invites confusion. I propose to get rid of usbdev->halted entirely, and replace it with usbdev->reject. In its new form it would be totally divorced from anything to do with endpoints being halted. Instead it would simply indicate that the core will reject URBs submitted for the endpoints that are marked. The usb_endpoint_running() and usb_endpoint_halted() macros would be replaced with usb_accept_endpoint_requests() and usb_reject_endpoint_requests(). This would be a weaker operation that usb_disable_endpoint() because it wouldn't affect URBs that are already queued and it wouldn't touch the HC hardware or driver state; it it would merely prevent new submissions. This change would only affect a few source files in the core, a couple of HCD source files, and only one driver file that I know of (in usb-storage). It would allow us to eliminate a rather awkward hack whereby the endpoint_disable routines set the maxpacket size to 0 in an attempt to prevent submissions. Finally, it would give drivers a simple way to stop automatic resubmission of URBs from within completion handlers (although the drivers would have to be prepared to deal with the resulting failures of submission). Does anyone have any comments or objections to this? Alan Stern ------------------------------------------------------- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
