On 05/01/2015 02:25 AM, George Spelvin wrote: >> Ok, I really have almost no sympathy for systems that don't use hardware >> flow control and yet expect no overruns to happen. Come on, we learned >> this decades ago that this is not a good idea. Don't force additional >> software complexity onto systems that refuse to use two hardware gpio >> lines properly. > > However, your idea of disabling input during console printk isn't > a legitimate use of hardware handshaking. By coupling the input and > output handshaking, you've created a lock ordering dependency. Dropping RTS during printk() does not mean CTS is also being polled; it isn't. Even on, autoCTS-enabled hardware, the wait_for_xmitr() will simply timeout after 10ms and proceed. So no chance of deadlock. > What if two such machines try to do a console printk simultaneously? Both printk()'s ignore CTS, so output regardless. > Either they ignore handshaking during the printk, or deadlock. > > In the use case I'm thinking of (cross-connected serial consoles), 100% > reliability isn't necessary; we just want a very high probability that > important debug messages aren't getting mangled. Regards, Peter Hurley -- 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
