Hello, Okash Khawaja, on mar. 28 mars 2017 15:35:08 +0100, wrote: > On Sun, Feb 26, 2017 at 2:48 AM, Samuel Thibault > <samuel.thibault@xxxxxxxxxxxx> wrote: > > - in the receive_buf2 method, > > - if read_buff_add is defined, just call it for each character and be > > done > > - otherwise, store the first received character in > > ((struct spk_ldisc_data *)tty->disc_data)->buf > > , call up() on the semaphore, and return 1 (to tell that you ate the > > character). > > > I don't fully understand how the return value of receive_buf2 is used > in flow control. According to Documentation/serial/tty.txt it is the > number of bytes processed by it, whereas comments on top of > tty_ldisc_receive_buf function's definition - which returns value > returned by receive_buf2 - say it is the number of bytes not > processed. I believe the comment is wrong: for instance n_tty_receive_buf_common clearly returns the number of processed bytes, and users (such as paste_selection, receive_buf from flush_to_ldisc) use it that way. You can probably submit a patch that fixes the comment already. > Also, is the call to tty_schedule_flip in spk_serial_in because we > returned 1 receive_buf2 so we have to manually tell it to flip buffer? (note: I meant spk_ttyio_in, of course) It's because we only returned 1, yes, i.e. we only ate 1 character, while there probably were more to read, but we didn't eat them, so we have to tell the tty layer when we are ready to eat more. Samuel _______________________________________________ Speakup mailing list Speakup@xxxxxxxxxxxxxxxxx http://linux-speakup.org/cgi-bin/mailman/listinfo/speakup
