On Wed, 11 Feb 2015, Dave Mielke wrote: > I'd appreciate some advice from anyone here who's familiar with using > signal-based notification (setting urb->signr) when using usbfs. It's working > correctly when this particular device is on, as well as when it's disconnected, > but I'm seeing what seems to be odd behaviour when the device is connected but > off. What do you mean by "turned off"? When the device is turned off, does it appear to the host controller that the device has disconnected from the USB bus? > Since querying the configuration and claiming the intterface both work, the > code goes ahead and tries to do I/O. The URB for expecting input is submitted, > the signal arrives, Which signal? Is this the signal for URB completion or the signal for device disconnection? Did you turn off the device while the URB was in progress, or was the device turned off all along? > but the non-blocking reap fails with EAGAIN. I tried a > blocking reap, which ended up waiting forever. My question, therefore, is: > Under what circumstances should usbfs code, after having received a signal, > expect to not be able to reap a URB, and how should it interpret this > situation? Currently usbfs does not allow users to reap URBs after the device has disconnected. I recently submitted a patch to fix this: http://marc.info/?l=linux-usb&m=142254896010033&w=2 > In case it matters: It's an interrupt input endpoint. The error indicated by > the signal (siginfo->si_errno) is -ENOENT, Indicating URB completion (since disconnection uses EPIPE). > which, as I see it, does make sense > because, with the device connected but off, it could mean that the USB > descriptors are available but that the endpoints can't actually be used. In > this situation, though, wouldn't the URB still be reapable with its status set > to -ENOENT? Not without that patch. > I see the following code in drivers/usb/core/devio.c, that does seem to be > doing some kind of urb cancellation: > > 518: if (as->status < 0 && as->bulk_addr && as->status != -ECONNRESET && > 519: as->status != -ENOENT) > 520: cancel_bulk_urbs(ps, as->bulk_addr); > > Whatever this code is for, it looks like it's specifically not being executed > if the error is -ENOENT. No relation to the problem at hand. Look instead at usbdev_do_ioctl(); one of the first things it does is check whether the device is still connected. Alan Stern -- 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
