Alan Stern wrote:
On Thu, 13 Dec 2007, Phil Endecott wrote:
[snip]
why does the host controller consider the data complete and send the
status stage after one packet of 8 bytes when the kernel does it, but
keep sending INs (which are NAKed) when I do it?
So the kernel guesses that the maxpacket size is 64 and tries to do a
64-byte transfer. No matter what the real maxpacket size is, the
result will always be a short transfer because the device descriptor is
only 18 bytes long. The host receives the first packet of the response
and then terminates the transfer, treating it as a short response since
it's less than the 64-byte maxpacket size.
Right! Thanks Alan, that explains it.
One observation: when my user-space control transfer times out in this
case, I don't even get the 8 bytes that I know the printer sent; the
copy_to_user() in devio.c's proc_control() is not called if
usb_control_message() returns an error. (I'm guessing that the kernel
has the partial data available at that point.) I noticed a similar
issue with babble; I have a device that returned two bytes when asked
for one (the mass storage number-of-luns IIRC) with the right value in
the first of those bytes; however, copy_to_user() is not called so that
data is inaccessible to a user driver. In the interests of a "level
playing field" between kernel and user-space drivers, should this be changed?
Evidently nobody ever tested the printer in the way you have, so the
firmware was never written to cope properly.
<rant>It looks as if at least half of the USB devices that I have are
disfunctional in some way or another. Device developers must hack
their code only until it "seems to work". What a mess.</rant>
Phil.
-
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
