On 02/12/2014 05:43 PM, Grant Edwards wrote:
A couple serial drivers I maintain check the value of tty->receive_room
to decide the max number of bytes to pull out of the UART's receive
FIFO and shove into a flip buffer.
tty->receive_room is not part of the driver<->tty core interface.
After checking tty->receive room to decide how many bytes to read, one
of the drivers uses this sequence:
tty_prepare_flip_string_flags(...)
^^^^^^^^^^^^
This was removed for 3.14.
<fill up char buffer and flag buffer>
tty_flip_buffer_push(...)
The other uses
for (i=0; i<count; ++i)
uart_insert_char(...);
tty_flip_buffer_push(...);
But, starting with kernel 3.12.0, whenSMP is enabled, tty->receive_room
is always 0 and never changes. With SMP disabled, it seems to work the
way it always has.
Starting with 3.12, receive_room is only used for line disciplines that
don't use flow control between the tty core and the line discipline
receive_buf (only N_TTY uses flow control).
This is because the N_TTY flow-controlled interface is lockless and
tty->receive_room is not supportable locklessly.
Is use of tty->receive room no longer supported for SMP kernels?
The use of tty->receive_room by drivers is not supported on any kernel.
How _should_ a serial driver decide how many rx characters there are
room for?
All of the flip buffer functions that reserve/use buffer space return
the space reserved/consumed. Is rx overflowing the flip buffers before
you can throttle the sender?
Regards,
Peter Hurley
--
To unsubscribe from this list: send the line "unsubscribe linux-serial" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
