Hi, On Fri, Aug 31, 2012 at 04:04:58PM -0400, Alan Stern wrote: > On Fri, 31 Aug 2012, Dmitry Torokhov wrote: > > > > > + /* Send a "check active" packet. The response will be > > > > read > > > > + * later and ignored. */ > > > > + ret = usb_control_msg(udev, usb_rcvctrlpipe(udev, 0), > > > > + 0, > > > > + USB_DIR_OUT | USB_TYPE_VENDOR | > > > > USB_RECIP_DEVICE, > > > > + 0, 0, "\x0A\x01A", 0, > > > > > > You probably can't send data from the .const section (as well as off > > > the > > > stack) -- they can be DMA'ed and there'll be issues with cache > > > consistency on > > > non-x86 arches. You should allocate the data with kmalloc(). > > > Although, on the second thought, maybe I'm wrong in this case... not > > > really > > > sure about sending -- receiving (to the .data section) could certainly be > > > harmful... > > > > Hmm, do we actually send anything here? The "size" passed to > > usb_control_msg() is 0 so I don't think we use that data at all... > > Good point. Perhaps the 0 is a typo, in which case data does get sent > and the buffer must be kmalloc'ed. If the 0 is correct then the buffer > should be NULL, not "\x0A\x01A" (and what's the purpose of the leading > '0' in the second byte?). > > In addition, although the bRequestType specifies USB_DIR_OUT, the pipe > value is usb_rcvctrlpipe. Is this transfer meant to be IN or OUT?
The primary issue is that I'm a USB newb working on a deadline. ;) My intention with this call was to send those three bytes out to the device. I tested this in Python using a libusb binding. Oddly enough, the code as written does in fact work in the sense that the device talks to the driver correctly after initialization (and without it it doesn't). Anyway, thanks for the review and sorry for being a bonehead. I'll resend. Thanks, Forest -- Forest Bond http://www.alittletooquiet.net http://www.rapidrollout.com
signature.asc
Description: Digital signature
