On Mon, 23 Mar 2009, Dave Mielke wrote: > [quoted lines by Alan Stern on 2009/03/23 at 17:38 -0400] > > >That was the literal requirement. On each successful data packet > >transfer, the toggle changes between 0 and 1. So after an odd number > >of data packets the toggle would be equal to 1 -- and that could be the > >source of a mismatch problem. > > Is the purpose of the toggle to be a simple way to see if the host and device > are out of sync? Yes. > Is it that the host sends its toggle state to the device and > the device refuses the packet and signals an error if its toggle state doesn't > match, or something like that? Something like that... If the toggle state doesn't match then the device accepts the packet but ignores it. (The same thing happens when the device sends a data packet to the host.) That's why your first transfer was being ignored. > Assuming I'm at least close to being right, is it also that a freshly opened > usbfs device starts with its toggle state at 0 (or 1)? No, not exactly. That is, opening a usbfs device file does not affect any toggle states. However in kernels prior to 2.6.28, releasing an interface (which happens when the device file is closed if you don't do it explicitly) is supposed to set the toggles back to 0. Similarly, usb_reset_device(), usb_set_configuration(), usb_set_altinterface(), and usb_clear_halt() are all suppposed to set the appropriate toggles to 0. > If so, how would the > device know that the usbfs device has been closed and reopened, and, therefore, > that the host's toggle state may have switched because of that? Prior to 2.6.28, every time an interface is released the kernel automatically does the equivalent of usb_set_altinterface(). If you use usbmon, you can see this request in the trace. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
