On 21 August 2013 01:08, Peter Hurley <peter@xxxxxxxxxxxxxxxxxx> wrote: > On 08/20/2013 06:52 AM, Viresh Kumar wrote: > That's really Greg's call whether he wants to take up RT-specific patches > into the regular tree. Yeah.. Lets wait for Greg.. >> One more thing: We are calling tty_flip_buffer_push() with (from interrupt >> context) and without (from process context) port->lock held. Shouldn't we >> >> make this flat, like don't acquire port->lock while calling >> tty_flip_buffer_push() as that may cause recursive locking? > > When you note that tty_flip_buffer_push() is called from 'process context', > I assume you mean kworker threads handling rx DMA. Besides the pty driver > and the fwserial staging driver that has loopback mode, I'm not aware of > any other drivers that do rx from process context. Okay.. And so most of the people call it from interrupt context (25+ of them, I am trying to fix for RT and others are already doing the right thing) and all of these must have set port->low_latency to false. Now my questions is, what exactly we want to protect in this function while calling it from interrupt or process context? For which we need a port->lock to be held by caller? There are drivers which are sustaining without a lock being held by caller and others shouldn't have any problem doing that... That might be a clean solution for Mainline and that will fix the RT issues we are facing :) -- viresh -- 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
