Russell King wrote:
The backup code is something I never properly reviewed, so no comments there. The tx_empty code I assumed would be a relatively rare event, except when closing the port (at which point you don't particularly care about errors anyway, not even the break flag since chances are you'll miss the following character.)
That "if" statement in the backup code does look a little dodgy, more than is perhaps required. I think it's correct, but I need to add a lock there in my patch to protect the LSR check.
Given that people might want to poll it for various reasons, I guess saving the status away should be done. However, there's a slight issue with working out which character the error is associated with. Careful locking may be the answer to that though.
I think as long as you hold the port lock while you grab the LSR and set the saved flags it will work.
As for start_tx, yes, though slightly harder to check. Maybe the code should be modified to reduce the number of potential LSR reads by reading the IIR first, and only if that shows no interrupt pending should the LSR be read (and the error flags remembered.)
The version of start_tx in 2.6.21 does check IIR first, and it only checks the LSR if UART_BUG_TXEN is set, so I assume that's not a big deal. I'll sleep on it tonight, look it over tomorrow morning, and resend the patch. Thanks, -corey - 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