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

Okash Khawaja okash.khawaja at gmail.com
Tue Mar 28 10:35:08 EDT 2017


On Sun, Feb 26, 2017 at 2:48 AM, Samuel Thibault
<samuel.thibault at ens-lyon.org> wrote:
> Samuel Thibault, on dim. 26 févr. 2017 02:50:05 +0100, wrote:
>> Please note in your todo for the input part, that ttyio will have to
>> call read_buff_add for each received character, when that method is
>> not NULL (that's actually the only driver using it, so we will really
>> need a tester for this exact driver).
> More precisely, it's the spk_ttyio_ldisc_ops->receive_buf2 method which
> should call read_buff_add for each received character.
> The step further will be implementing spk_ttyio_in and
> spk_ttyio_in_nowait.  I believe the easiest way is the following:
> - define an spk_ldisc_data structure containing just one character (buf),
> and a semaphore.
> - on ldisc_open, allocate a pointer to such structure, set
> tty->disc_data to point to it, and initialized the semaphore to 0
> tokens.
> - 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

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?


More information about the Speakup mailing list