close() handler of tty driver called for port that's not open?

[Grant Edwards <grant.b.edwards@gmail.com>]

Why does the tty layer call my tty driver's close() handler on a port
that's not open?

The scenario I've run into is that my open() handler is called for a
serial port that's not currently available, so I return -EBUSY.  The
libc open() call returns an error:

  [Errno 16] Device or resource busy: '/dev/ttySI0'

But then after the open has failed, my tty driver sees a call to
close() the device which failed to open.

Why does the tty layer try to close a device that isn't open?

Does the tty consider a device to be open even if the open() handler
returned an error?

The problem is that my driver keeps a usage count on the port so it
can clean up some internal stuff when the last user closes a port.

I only increment the usage count when an open is successful.  That
doesn't work very well when the tty layer calls close() on a device
regardless of whether or not it was able to open it first.

Does the tty layer guarantee that the number of close() calls will
match the number of open() calls regardless of whether the open()
calls succeed or not?

If so, has that always been the policy, or is calling close() on
non-open device a new feature?

-- 
Grant Edwards               grant.b.edwards        Yow! I want to mail a
                                  at               bronzed artichoke to
                              gmail.com            Nicaragua!