>...
>
>The obvious intention is to give kind of help for drivers to deal with
>devices which do return request_error (EP0-STALL) for SetInterface request
>on interfaces with single AS - as described in 9.4.10. However, I think
>this implementation has the potential to break USB standard conformance:
>
>* 9.4.10 _permits_ the device to return request error ("may") - but by no
> means _requires_ it to do so. The snippet above however completely
> prevents SetInterface request to be ever sent to single-AS interfaces.
> Since the SetInterface request basically implies a reset of the affected
> endpoints it might be required nevertheless. IMHO the request should (at
> least) be sent to the device to give it a chance to act as intended.
That a point, BUT what if your device doesn't stall ?
Doing this, you'll break (bossibly all) OnSpec-based Card readers (you'll
find chips in ACOMdATA, DataFab, Imation, ... products).
(code path: storage reset -> usb_reset_device() ..)
I know this is really a device bug, but a usual, I it works under Win it ......
And as far as I colud see, WinXX won't do a set iface..
Sending the 90c36 a SET_INTERFACE totally kills it; only loss of power will
get it back to life.
>A simple improved error test in the driver
>
> if (res && (res!=EPIPE || iface->num_altsetting!=1) {
> /* treat as error */
> }
Too late. OnSpec's will be dead.
set_interface will never be called from the core, except for a
usb_reset_device(), right ?
Notably: set_interface won't be called automatically during a normal
plug-in sequence, right ?
How about my original proposal, checking iface->num_altsetting!=1 there,
and only calling set_interface then ?
Then, in case a drivers knows what it's doing, it can still go ahead..
- sda
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
