I'm pleased I asked now. I had no idea that you could even submit a bulk URB to an interrupt endpoint. I would have submitted an INT one and then probably fallen foul of the very code you mention.
Perhaps that needs patching, so that the devfs code ensures that the urb is cancelled before returning it. It's odd that the two types of hardware treat the interrupt case where interval == 0 differently. Is either of them wrong by the specification or are they both right? It sounds from what you say that one should never submit any interrupt URB with a zero interval because you don't really know what's going to happen (or you should code around ensuring that the thing is cancelled). Sounds like zero-interval interrupts should always be submitted bulk. Similarly it seems that submitting an interrupt usbdevfs_urb with an interval would be a bad thing since that will requeue on both types of hardware but still get freed. Thanks for the reply - that was very helpful. Roland On Thu, 14 February 2002, Dan Streetman wrote: > > > On Wed, 13 Feb 2002, Roland King wrote: > > >The device has interrupt endpoints. I see special transfer ioctls > >for bulk, but not interrupt. I've been assuming that I need to > >submit a usbdevfs_urb and then go and reap it. Does that sound > >about right? Is there any sample code or a good example which > >uses these functions? > > Yes, you submit a BULK type usbdevfs_urb to the interrupt endpoint. > It gets one packet of data. You can submit multiple ones that will > queue up. and I'm guessing 'reap' is REAd Pointer, not like the grim > reaper (although maybe it is...:) > > >Unrelated question, if you're writing a normal device driver and > >your device has interrupt endpoints and you submit an interrupt > >urb, will you be called each time there's an interrupt continuously > >until you unlink the urb, or do you have to resubmit it? I found one > > Yes, unless you're on UHCI hardware and interval == 0. OHCI resubmits > regardless of interval. On UHCI, 0-interval behaves like BULK (except > for its priority). > > Note you should not use interrupt type usbdevfs_urbs if your hardware > is OHCI, as OHCI will resubmit it > http://lxr.linux.no/source/drivers/usb/usb-ohci.c#L486 > then you reap it > http://lxr.linux.no/source/drivers/usb/devio.c#L978 > which frees the URB (part of the struct async) > http://lxr.linux.no/source/drivers/usb/devio.c#L188 > and then bad things happen (kernel accessing freed memory). > > > -- > Dan Streetman > [EMAIL PROTECTED] > -------------------------------------------------- > 186,282 miles per second: > It isn't just a good idea, it's the law! > > > _______________________________________________ > [EMAIL PROTECTED] > To unsubscribe, use the last form field at: > https://lists.sourceforge.net/lists/listinfo/linux-usb-devel _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
