Cannot read using USB Skeleton Driver

Felix Varghese felixv1986 at
Wed Sep 21 09:29:57 EDT 2011

With some modification, I have finally made the skel driver work with
my device. I think I have some initial theories about the root cause
of the problems that I ran into with skel:

1) The condition if (!dev->processed_urb) is always false in the
beginning and this induces a wait without any scope for completion, so
it has to be removed.

2) A blocking read and blocking write cannot happen simultaneously.
This is because in read, we go to sleep after locking a mutex
'iomutex'. Before writing, we try to lock the same mutex, so if we try
to write() from one thread (or process) while waiting for read() to
complete in another, we will have both threads blocked, waiting
indefinitely for each other (the device won't respond until you send
data to it). This can be fixed by unlocking the mutex before entering
into the wait but then that mutex might be there for a reason and I
might be doing the wrong thing.

3) If the buffer associated with your read urb is not big enough to
accommodate the packet that arrives over USB, the transfer request
will fail with error -75 in the completion callback. We could handle
this by either propagating the error back to the user or by issuing
transfer requests with big enough buffers and keeping the data
buffered until the user asks for it. Then we could give as much data
as he asks for and keep the rest buffered. But in the latter case, the
user may issue a read() call expecting a transfer to happen, but he
might not necessarily see one (in case there is data already
buffered). Also the buffer size would be somewhat arbitrarily chosen
which is not nice.

Does anybody have anything to add or oppose on this or would you guys
rather have me send a patch along with my changes?


More information about the Kernelnewbies mailing list