On Fri, 14 Dec 2007, Phil Endecott wrote: > 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?
Actually it _is_ a level playing field. The USBDEVFS_CONTROL ioctl calls the kernel's usb_control_message() routine, which returns the error code if an error occurred and the number of bytes transferred if there was no error. The number of bytes isn't made available when an error happens; that's just as true for kernel drivers as for user drivers. If you want to know the actual transfer amount, you have to use USBDEVFS_SUBMITURB. Alan Stern - 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
