> I hate functions that have "bool" variables like this, it's a mess and > can cause them to do different things so you always have to look up the > details. Agreed, but it was a magic flag in a structure before I made it explicit like that, so I think it's a big improvement. I think I improved the original maintenance nightmare of a patch, but I'd be delighted fo have someone with a broader understanding of the code clean it up even more. > Why isn't this a problem with other uarts and slow baud rates? Why > hasn't this problem ever been reported in the past for other uarts? Is > this really the best/only way to solve this? The root cause is the emergency console output feature which uses the UART with interrupts disabled. UARTs which don't support that don't have the issue. Console output can be long, and the input FIFO can overflow in the meantime. The designers of the feature assumed the UART would me dedicated as a console, so would not be receiving much input. However, here we have a use case that does have significant input. The change is to poll for input while polling for output. However, this leads to a potential deadlock. Most output can simply be blocked for the diration of the emergency print. However, a SysRq also uses the same emergency console output feature, so there's a re-entrancy problem. This code takes the simple approach of halting input polling if SysRq is received (before the following action character is received and must be acted on). -- 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
