Warning about not setting tty->port: what to set it to?

I maintain a serial card driver which, starting with kernel 3.7, produces this warning when a port is opened:

tty_init_dev: ttyXYZ driver does not set tty->port. This will crash the kernel later. Fix the driver!

The driver still seems to work fine, but apparently I shouldn't expect it to continue to do so.

What am I supposed to set tty->port _to_ ?

Obviously, it's supposed to point to an instance of the type (struct tty_port).

Is there somewhere in particular I'm supposed to get that structure instance from?

Am I supposed to allocate/clear one when the port is opened and free it when the port is closed? Or does the contents the structure pointed to by tty->port need to be preserved?

Am I expected to do anything with the contents of that structure?

Or am I just providing some storage space for use by the tty layer code?

Grant Edwards               grant.b.edwards        Yow! I'm young ... I'm
                                  at               HEALTHY ... I can HIKE
                              gmail.com            THRU CAPT GROGAN'S LUMBAR
                                                   REGIONS!

I've been looking at 3.7.2 in-kernel tty drivers to try to figure out what to do about this, and I don't understand how the in-kernel drivers are avoiding the same problem I'm seeing.

I've looked at three other tty drivers: amiserial.c, rocket.c, cyclades.c:

Based on some examination/experimentation, it seems the check for tty->port is done during driver "installation" and occurs _before_ a tty driver's open() function is called().

But, amiserial.c doesn't set tty->port until the open() function is called. How does the amiserial driver avoid the warning and stack trace?

AFAICT, the rocket.c and cyclades.c drivers don't set tty->port at all.

What am I missing?

Grant Edwards               grant.b.edwards        Yow! When this load is
                                  at               DONE I think I'll wash it
                              gmail.com            AGAIN ...