On Tue, Mar 28, 2017 at 4:11 PM, Samuel Thibault <samuel.thibault@xxxxxxxxxxxx> wrote: > 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. Right, so either we process all characters, return count (the argument to receive_buf2) and don't bother with tty_schedule_flip, or we process less than count and call tty_schedule_flip. Thanks very much for explaining Okash _______________________________________________ Speakup mailing list Speakup@xxxxxxxxxxxxxxxxx http://linux-speakup.org/cgi-bin/mailman/listinfo/speakup
