On Mon, 14 Jul 2003, Gary Ng wrote:

> Hi all,
> 
> I'm currently writing a very simple USB driver for a printer.
> I've a few rookie questions that I hope you guys can give me some
> pointers.

Okay.  But bear in mind that there already is a USB printer driver.

> First of all, I decide not to use MOD_INC_USE_COUNT/MOD_DEC_USE_COUNT
> coz I read it somewhere that it's no longer necessary if I define
> "owner:THIS_MODULE" in my file ops.
> However, after I open() the printer device and then unplug the printer,
> I still have a module use count as 1, is this expected behaviour? 

Yes; so long as the device is open the use count will be nonzero.  When 
you close() the printer device the use count will be decremented.

> Do I need to do MOD_DEC* inside disconnect()?

No.

> How, from the point of view of the driver, should I handle a 
> disconnection of USB device after open() is called?

You should set a private flag, so that your driver's open/read/write/ioctl
routines will know that the device has been disconnected and won't try to
access it.  When release() is called, it can check that private flag -- if
the flag is set (and the usage count is 0) it can deallocate your internal
data structures.  Also, you always have to keep track of whether or not
the device file has been opened (a usage count): if it's not open then
disconnect() can deallocate the data structures right away.

Note that on SMP architectures there is a race between open() and 
disconnect().  You will have to use a static semaphore to prevent the 
possibility of someone calling open() (thereby trying to access your data 
structures) at the same time a disconnect() occurs (thereby freeing 
those same data structures).

> I was thinking to keep the device structure around so that I can
> reuse it when the printer is re-connected again (when probe() is
> called). Is there any well-known policy/procedure to handle such 
> situation?

Yes there is -- you shouldn't do it.  Deallocate the structure; the next 
time probe() is called start fresh from the beginnning.  After all, this 
might be a different printer being plugged in.

Alan Stern




-------------------------------------------------------
This SF.Net email sponsored by: Parasoft
Error proof Web apps, automate testing & more.
Download & eval WebKing and get a free book.
www.parasoft.com/bulletproofapps1
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel

Reply via email to