Hacker News Reader

Comment by makomk | Hacker News Reader

Wait, if I'm reading this correctly there's no safe resume recovery time which can be guaranteed not to cause devices to drop off the bus. The kernel could wait 10 minutes and devices could still require more than that. That seems like a pretty major issue with the USB specification.

View on HN

If you issue a database query, you have no particular guarantee that it's going to complete in any finite amount of time. At some point, you simply throw up your hands and say it would be unreasonable to wait any longer, and accept the resulting error condition.

No, the spec is saying don't issue a request at all for "at least" 10ms. "At least" because you might have to wait longer, who knows how long, until it's safe to issue a request without triggering a disconnect.

I don't understand that, if devices can take as long as they please then why give the 10ms delay at all? It'd be like telling the hardware engineers "you're not allowed to wake up your device for at least 10ms". Is that just the spec trying to say "this should cover most use cases" and it turns out that's not really the case in practice? Or maybe it's an expected limitation of the technology that it would be nearly impossible to ready a device within 10ms, so the spec is saying it would be pointless to issue a request before that time?

I could simply be budgeting room for the USB core itself to wake.

I imagine it's something along the lines of "ok device, you have 10ms to play with the link before anyone's watching, do what you need to do." For example, electrically detecting the wattage of the power supplied over the link by examining its responses to various inputs. (I have no idea whether that's at all relevant here or if it's even the right part of the stack, I'm just offering an idea of why the device might like the controller to say "I'm not watching right now".)

> No

I don't know who you think you're disagreeing with, but it clearly isn't me.

acchow is disagreeing with your database query likeness. Your comment was effectively saying that it's just waiting until it's ready. And this is clearly something that can be disagreed with.

Based on the way this article is worded, it seems like there is no way to check when TRSMRCY is over. Imagine if you were waiting for a database query and if the database wasn't done thinking yet, simply accessing the socket would make the query abort.

Your understanding of the problem is in error, and will be corrected by reading the linux-usb thread linked to by the article.

Good! But that doesn't mean your original comment was infallible, since it didn't actually clarify such a thing.

The hub knows when the device is ready; just query it. A constant timeout is not needed. A give-up timeout might be employed, but there's no reason that can't be 100's of ms, nobody is waiting on that and it doesn't usually happen anyway.

Reply on news.ycombinator.com