> From: Paul Kranenburg <pk@cs.few.eur.nl>
> Date: Fri, 31 Oct 1997 21:42:46 +0100 (MET)
> 
> I fixed the race condition that was causing this earlier this year
> in the previous version of the zs driver.  I fear that change was
> not ported to the current driver.

I looked at that when you posted the message, but I thought the
new version of the driver was OK.  Maybe I was wrong.

It is supposed to work this way:  If the kernel calls zscnputc when
the transmitter had been busy, it will wait for it to be non-busy,
and then make it busy again.  The interrupt-driven output should still
get a transmit-complete interrupt, after the last character written by
zscnputc finishes going out.  This was how the old com driver did
things as well, and the only "problem" with the method is that it
will cause extra transmit complete interrupts (no big deal).

After looking again, it appears that the new <arch>/dev/zs.c
does not ignore supurrious interrupts.  Should it?

BTW, I think doing deferred output for zscnputc is unnecessary.
The extra TX interrupts will be rare, and are much simpler.

Gordon