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@xxxxxxxxxxxxxxxxxx - To unsubscribe from this list: send the line "unsubscribe linux-serial" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
