Alan Stern schrieb:
In the future don't worry about such things. It's pointless to
introduce barriers like this for people who want to read your code.
Just include the patch inline in your email message, as described in
Documentation/SubmittingPatches.
OK, checked.
It looks basically okay, but there are a couple of things worth
noting:
This whole business about searching for the mass-storage
interface and endpoints is unnecessary, because that work has
already been done. The interface is us->pusb_intf and the pipes
are us->send_bulk_pipe and us->recv_bulk_pipe. All that stuff
should be removed.
You shouldn't return USB_STOR_TRANSPORT_GOOD from option_ms_init;
return 0 instead. I have already submitted a patch changing the
existing places where this mistake occurs.
I tried not to touch other people's code (still being shy) but I
will change and test all that. And post again inline.
Bulk send/receive errors during the inquiry process are not exposed,
instead the result is the same as with any "non-Option" device: do
nothing. Is that OK?
Yes. Especially since some people would argue that this code should
never do anything in the first place! :-)
I really earned that one, didn't I? 8-)
You might want to go ahead and add it, then. What happens with the
Option, if the mode switch succeeds and you try to read the CSW?
It usually succeeds (when looking at the Windows sniffing log) but
the switch is already initiated and "unavoidable" for a moment (~3
ms) later; no difference when skipping the CSW reading.
I can add it as an additional safety measure; if the patch is
accepted AND generally working, the switch command should happen
only to the right devices.
Josua Dietze
--
Man is the only creature on earth enabled to take a
warm meal while flying! Loriot
--
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
