Hi,
>> The problem is the uart_flush_buffer() call we see after uart_open() in
>> 4. If doesn't seem to come from serial_core (only called from uart_close
>> / uart_hangup), so presumably it comes from the TTY core or
>> userspace. Could you add a bit more debug to figure out where exactly it
>> comes from?
Michal> Last week I have also implemented simple ioctl function for
Michal> uartlite - just printk to see what happen. Look at the second
Michal> log below.
Michal> uart_open(0) called
Michal> ulite_ioctl 5401 bff76a18
Michal> n_tty_ioctl
Michal> ulite_ioctl 540b 2
Michal> n_tty_ioctl
Michal> n_tty_ioctl_helper TCFLSH
Michal> tty_perform_flush TCIOFLUSH
Michal> tty_perform_flush TCOFLUSH
Michal> tty_driver_flush_buffer
Michal> uart_flush_buffer(0) called
So your userspace is calling tcflush, and serial_core responds by
flushing (dropping) the buffer. That seems like expected behaviour to
me.
This is presumably from the busybox getty applet, which does:
static void termios_init(struct termios *tp, int speed, struct options *op)
{
speed_t ispeed, ospeed;
/*
* Initial termios settings: 8-bit characters, raw-mode, blocking i/o.
* Special characters are set after we have read the login name; all
* reads will be done in raw mode anyway. Errors will be dealt with
* later on.
*/
/* flush input and output queues, important for modems! */
tcflush(0, TCIOFLUSH);
You could change that to a tcdrain() if that's not what you want.