On Wed, Mar 04, 2009 at 08:04:53PM -0700, Pete Zaitcev wrote: > This is not how USB works. Unless I misunderstood you, you think it's > some kind of overcomplicated Ethernet. But in reality the properties > of the bus are completely different. You may rest assured in this case > that the device simply did not send the data. I was thinking more along the lines of different behaviour on the bus looking different enough to the device to confuse it. I don't fully understand how a set_configuration() could change behaviour like we're seeing. I know that the device can't send data unless asked, but I'm not as confident in understanding how "toggles" work, etc. If the device thought it was using a different interface or configuration (although I'm not sure how) and somehow the intended response went into the ether, is it even remotely possible that the host's USB bus settings could be a factor? I hacked Barry to pretend that the successful response came in after a timeout, and it proceeds normally. The kernel change that my git bisect found removed a default set_interface, so I tried adding a usb_set_altinterface() instead of set_configuration(), and yes, that fixes the timeout too. :-) Hopefully this fixes the issue that Paul is seeing as well. Thanks for all your help. - Chris -- 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
