RM9000 code broken in 8250.c

[Thomas Koeller <thomas@koeller.dyndns.org>]

Hi,

while investigating breakage of the RM9000 code in
drivers/serial/8250.c, I found that my problems are
caused by commit 40b36daad0ac704e6d5c1b75789f371ef5b053c1.
My device has the characteristic of not generating a
'transmitter empty' interrupt immediately if interrupts
are enabled while the transmitter is empty, it needs to
be kicked by transmitting a character first. Before
commit 40b36daad0ac704e6d5c1b75789f371ef5b053c1 this was
taken care of by code in serial8250_startup() that probed
the hardware for this bug an set the UART_BUG_TXEN flag,
which then modified the behavior of serial8250_start_tx()
to take the bug into account. This used to work well for
my device.

The commit introduced another check for the same condition
which is done earlier in serial8250_startup(), and causes
the driver to use a periodic timer instead of the hardware
interrupt. Now my device uses that timer, while it was
perfectly capable of using the serial port transmit
interrupt before.

I wonder why a new workaround has been introduced for a
problem for which there had already been a (far superior)
solution. Didn't this existing solution solve the problem
for the hardware in question? If so, wouldn't it have been
possible to modify the existing solution instead of adding
another one that conflicts with existing code that depends
on the old code?

regards,
Thomas
-- 
Thomas Koeller
thomas@koeller.dyndns.org