Hacker News new | comments | show | ask | jobs | submit login

this is wrong interpretation actually.

There is no "maximum" for a reason. Because it should be evaluated as "hey hardware developer, you will have guaranteed 10 ms from System Software to resume". If you don't wake up in 10ms, you are clearly violating the spec. states: After a port is reset or resumed, the USB System Software is expected to provide a “recovery” interval of 10 ms before the device attached to the port is expected to respond to data transfers. The device may ignore any data transfers during the recovery interval. After the end of the recovery interval (measured from the end of the reset or the end of the EOP at the end of the resume signaling), the device must accept data transfers at any time.

Nothing there says that the hardware must be ready at or after 10ms. It simply says that software can't ask for anything before 10ms is up. Software has to wait 10ms, and then might have to wait longer.

Yep, the mentioned 7-14 table makes this very clear: it's a big-ass table of timing names with a column for minimum and a column for maximum (and a bunch of other columns for e.g. timing unit), where either column may be empty (and for many timings only one of them is filled).

In that table, TRSMRCY has a minimum value (of 10ms) but no maximum.

Bear in mind that here, something which is a minimum from the point of view of the OS is a maximum from the device's point of view. If the OS is allowed to use any value above 10ms for TRSMRCY then the device can take at most 10ms to prepare itself because the OS can send a request at any point after that.

That interpretation doesn't seem to make much sense though, because there would be no point in specifying the 10ms at all - it means nothing, and doesn't put any restrictions on anyone.

An alternative interpretation is that by forbidding the host from issuing any commands for that initial period, the target device could (if it happens to be expedient) do all sorts of otherwise spec-violating things, safe in the knowledge that nobody will ever find out[2]. After that grace period, it has to go back to playing by the rules, but doesn't necessarily have to be operational. Whether or not it's operational yet can be queried[1] (after the first timeout), and a decision to use it, retry the query after a fixed or variable additional fallback, or mark it as failed.

A better spec might recommend or mandate values for fallback quanta and repetitions, or a maximum bound on the delay, rather than leaving it vendor-gets-to-choose.

I didn't look too hard, but a decently marked timing diagram would be nice, and might make it easier to spot the unbounded nature of it, rather than having to cross-reference the inline '10ms' value with the minmax table elsewhere.

[1] At least, if I understand it correctly. If accessing the status info uses the same mechanism as general traffic, it's obviously subject to the flaw described, and this interpretation is wrong.

[2] c.f. https://en.wikipedia.org/wiki/Don%27t-care_term and perhaps https://en.wikipedia.org/wiki/Virtual_particle

It does indeed put restrictions on the software author not to expect hardware to be ready in less than 10ms. Perhaps the specification is somewhat nonsensical. That does not permit the software author to create restrictive interpretations. IMHO, it informs the software author that flexibility should be allowed in their code.

But under your interpretation, the software can't expect the hardware to be ready in less than 100ms, 10s or 10 minutes either - so the value "10ms" is meaningless.

Indeed. And the software should continue to wait for readiness or decide when to give up. Giving up at the 10ms mark isn't against spec, it's just not prudent.

"After the end of the recovery interval the device must accept data transfers at any time." simply says that "hardware must be ready (in order to accept data transfer)"

But the "recovery interval" is not defined, leaving the device to decide what its "recovery interval" is and guaranteeing that software will not expect it to be less than 10ms.

actually it is defined as 10ms.

USB System Software is expected to provide a “recovery” interval of 10 ms before the device attached to the port is expected to respond to data transfers

Is there anything in the spec suggesting that the hardware can take longer than 10ms? Given the phrasing in the spec ...

> Resume

> The USB System Software must provide a [minimum] 10 ms resume recovery time (TRSMRCY) during which it will not attempt to access any device connected to the affected (just-activated) bus segment.

> Reset/Resume Recovery Time

> After a port is reset or resumed, the USB System Software is expected to provide a “recovery” interval of [at least] 10 ms before the device attached to the port is expected to respond to data transfers.

... I would say that thinking the hardware can safely take more than 10 ms seems like a naive interpretation. You may note that system calls like usleep(10) sleep for "at least" 10 ms; there's no upper bound. The spec simply reflects this fairly typical aspect of software.

The true intention of the spec is academic at this point. There are millions upon millions of devices out there with one interpretation and they're not changing. Linux can either increase the grace period or be tarnished as having bad USB suspend.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact