> > When keyspan_pda_rx_interrupt gets the RETURN from the external
> > terminal it calls tty_flip_buffer_push which queues up flush_to_ldisc.
> > When this is run (on interrupt time) it calls tty->driver.put_char
> > twice to echo CARRIAGE RETURN and LINEFEED. put_char calls
> > keyspan_pda_write. The CARRIAGE RETURN gets through, but when
> > keyspan_pda_write is called again to write the LINEFEED, urb->status
> > is -EINPROGRESS and so it sleeps. Panic.
>
> Eeek. Not good.
>
> I personally don't think that the wait queue needs to be in the
> keyspan_pda_write function, but since I didn't write that part of the
> driver...
Sounds reasonable. I added that extra test (and was thinking of adding more,
hence the if(0) clause) in the hopes of accomplishing two things:
non-blocking writes that occur while the tx urb is in-flight shouldn't block
blocking writes should write at least one character
I haven't yet understood the file->f_flags usage well enough to be confident
about the test to accomplish the first one. The sleep was to make the second
one work even if the URB was in flight (otherwise users might just spin until
the URB comes back, which felt like a waste). I never did quite grasp what the
tty layer is doing; if it handles these cases then that code can go away.
> Since the visor, generic, and another driver that I have written all use
> this, and I have not had any problems with the data being sent, I don't
> think it is an issue.
I'd be happy to change the driver to match the behavior of the other devices.
I just hope to get the non-blocking case right.
Let me know what you think.
thanks,
-Brian
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
