[patch 6/6] staging: speakup: Migrate acntsa, bns, dectlk and txprt to ttyio

[Okash Khawaja]

On Tue, Mar 28, 2017 at 4:11 PM, Samuel Thibault
<samuel.thibault at ens-lyon.org> 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 at ens-lyon.org> 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