On Wed, 24 Oct 2007, Phil Endecott wrote: > > No. That is, this is one meaning of the word "babble", but in this > > context "babble" means the device was still transmitting when the host > > expected it to stop. In other words, the device sent a larger packet > > than the host expected, like a 64-byte packet when the host expected > > only 18 bytes, or a 3-byte packet when the host expected only 2 bytes. > > Thanks Alan. Like declaring a bMaxPacketSize0 of 8, and then when > asked for 18 bytes of device descriptor, returning all 18 in one > packet?
Exactly. > That looks like it's my problem! > > > Aside: while I was trying to understand this, I stumbled upon this code > in core/hub.c. This is in 2.6.19; apologies if it has changed since > then. In hub_irq(): > > bits = 0; > for (i = 0; i < urb->actual_length; ++i) > bits |= ((unsigned long) ((*hub->buffer)[i])) > << (i*8); > hub->event_bits[0] = bits; > > This is processing the data from a hub's status-change endpoint. My > concern is what happens if more than one port's status changes within > the endpoint's polling interval. It's OK if the hub returns a single > report with all of the appropriate per-port bits set, That's what will happen. > but is it allowed > to return two reports, one showing one port change and a second also > showing a second port change? No. Interrupt endpoints don't pack more than one message into a single packet. Since the device doesn't know what the host expects, it has to assume the host expects to receive only one message. > I believe that in this case the code > above will attribute the second report to non-existent port numbers and > subsequently ignore them. (I'm not worried about the MaxPacketSize / > babble here - though thinking about that was how I came to look at this > code - it seems to be 16 bytes for my hubs.) > > My concern is less about the correctness of the code - after all, if > hub status change reporting was broken, someone would have complained > by now - but more about whether I correctly understand how an interrupt > endpoint works. In general, if an additional event occurs in the > device before a previous one has been seen by the host, does the new > status replace the old one? It depends on the device, or the device's class. With hubs, each report is supposed to include the current change-status of every port, so if two ports have had status changes then they will both be included in the report. Other sorts of devices might work differently. > This would be similar to how a hardware > interrupt-status register would work. However, thinking about a > keyboard you certainly don't want new keypresses to replace old ones > that have not been read yet! So, from the point of view of a device > (e.g. a microcontroller) providing a general-purpose interrupt endpoint > feature, should new data be queued behind old data, or should it > replace it? Like I said, it depends on the device. A keyboard device might store key-press and key-release events in an internal buffer so that they can be presented to the host in the correct sequence. However the USBHID protocol specification specifically allows keyboards to drop events if they occur too quickly. BTW, in spite of the name it's a mistake to identify interrupt endpoint behavior too closely with actual hardware interrupts. You're better off thinking of them as bounded-latency channels. If an interrupt endpoint has a polling period of 32 ms, then it is guaranteed the device will have a chance to report each event to the host within 32 ms of the time it occurs. With bulk or control endpoints there is no such guarantee. Alan Stern ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ Linux-usb-users@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-users
