Hi! >>>>> "eON" == ext Oliver Neukum writes: > Am Donnerstag, 21. Oktober 2010, 12:14:22 schrieb Yauheni Kaliuta: > > I think, that the host is wrong here: the line status doesn't depend of the > > application running and should be checked by host. Moreover for me looks > > reasonable, that host is polling interrupt endpoint as soon as it claims > > the interface in this case (well, I see in usb spec only something like: > > > > The client software and device can depend only on the fact that the host > > will ensure that the time duration between two transaction attempts with > > the endpoint will be no longer than the desired period.) > > > > Note, that windows host behaves exactly that way. > > > > What do you think and what I missed? > That would mean a lot of pointless bus traffic. And the device would > have to tolerate a stop in polling if the driver were not loaded. Perhaps > the very first result should be discarded in case it was stale? On which side? Host's? How host can now, that it's the "stale" one? It enables notifications, then sets DTR and gets "NO CARRIER" -- all correct. On gadget side? Should gadget cancel the notification if it was not served in the bInterval period or something like that? That's very hackish and racy. I see some possibilities: 1) What I proposed: host keep polling. Most correct, but pointless bus traffic. 2) Since DTE (host) should check DSR only after DTR is set, gadget should skip any notification after host removes DTR. When DTR is set, it sends the notification. My nokia n82 behaves that way. From one side it looks like a violation of the spec, on the bus there are 2 notifications about the same, but according to the spec, the notification should be send only if there is a change in the line state. But well, internally there was a change, just there was no notification sent. Problem here is with the current linux host driver, which remembers the state of previous session, it (host) may start to send data before DSR and DCD actually set on the gadget side. So, the race again. 3) host side doesn't rely on the previous state, reset it and expects a notification after it sets DTR. Looks reasonable, but if there is no change on the gadget side (it may keep application running, carrier ..., why not?), then host never receive the notification. -- WBR, Yauheni Kaliuta -- 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
