On Fri, 26 May 2006, Paul Giblock wrote: > > Perhaps it will be good enough to limit the timing between URBs generated > > by your driver. URBs coming from somewhere else won't be your > > responsibility. > > > > Thats exactly my plan. I'm just having trouble devising a good way to do > this.
Do all these URBs get created when the user writes to your driver's device file? If they do, then a simple approach needs only a mutex (so that only one write can happen at a time) and the value of "jiffies" as of the last URB. If the current transfer is too soon after the last one, do an interruptible sleep for the appropriate time before submitting the URB and releasing the mutex. This is much easier than keeping track of a queue of pending commands. > > If you want to be really clever, you can keep track of the status messages > > and reset the device if they no longer arrive as expected. > > Unfortunately the only way to reset this device is by cycling power > (the device has an external power source). Too bad. > I think what I'll end up doing is using a circular buffer. The file > operations will cause commands to be inserted into the cirular > buffer. There will a kthread that will send the next message from the > buffer and then sleep for the needed interval. I could use a timer > instead of a kthread, but at least the kthread's function will not be > in_interrupt. If you do it this way don't use a kthread, do use a timer. The fact that it runs atomically doesn't matter. > Does this sound fair or am I doing alot of work for something the > kernel may already provide me? I know the kernel has a ton of data > structures for queuing and locking but I don't think any of them apply > to my problem. I don't know of anything in particular that would be applicable. Alan Stern ------------------------------------------------------- All the advantages of Linux Managed Hosting--Without the Cost and Risk! Fully trained technicians. The highest number of Red Hat certifications in the hosting industry. Fanatical Support. Click to learn more http://sel.as-us.falkag.net/sel?cmd=lnk&kid=107521&bid=248729&dat=121642 _______________________________________________ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
