On Tue, Nov 30, 2021 at 03:19:54PM +0800, chaozeng wrote: > > > Dear all > > I have a question about the output buffer, it just related hardware > flow-control enabled. > > > Question Description: > > When the flow control works, rts works. At this time, the sender stops data > transmission and exits the sender with interrupt. > > We observed that the output buffer was not empty. > > But > > 1. When the serial port device is used again, it will hang when modifying > the properties.(We think the buffer is not empty, change termios property is > not OK). > > 2. the receive side could receive these output buffer(before) next > time.(seems strange) > > Reproduce steps: > > 1. Connect the send and receive side. enable hardware flow-control for > both Send side and recv side. (start recv.py then send.py)(refer > attachments) > 2. Waiting for RTS desseart. > 3. Close the send side using CTRL+C > 4. Using stty to show or set the uart attributes(it would hang). and > start the second round, the receive side would receive the data last > sent. > > I found FTDI usb-serial device would sent the data out when flow-control is > enabled when closing the port ,but the ti omap_8250 device could not sent > the data out and keep the buffer. > > the behavior is not the same between several serial ports. What hardware are you testing for all of this and what drivers for these devices? And what kernel version? Note that usb-serial devices are very odd and cheap and do strange things because they are so cheap. They also have the uart hardware off at the end of a usb connection and so are not able to be fully controlled by the operating system for some devices (while others are, but those are usually more expensive devices.) Also there are many "fake" usb-serial devices out there that sometimes work differently than the real ones, so watch out as well. And further, when using stty for some usb-serial devices, they used to reset their settings when stty closed, making the tool pretty useless. Depending on your kernel version and device, you need to watch out for this and not rely on stty, but rather the program when you start it up needs to set the proper line settings that you need for the device and never rely on a previous program getting the state set up properly. Also note that when closing a port (you are aborting a program while it is running), the state of the uart/tty device is not always in a known state to userspace anymore. So what exactly is the problem that you are trying to solve here and what normal workflow has programs being aborted while running? > Questions: > > I'd like to know the common handle logic about the output buffer. > > When closing the port, should the output buffer to be sent out or be cleared > no matter flow-control is enabled? Depends on the hardware :) > Who should be response for these output buffer. kernel or userspace > application? If the data is already sent to the kernel from userspace, how can userspace be responsible anymore? > If we keep the output buffer after closing the port, what's thex intend of > this? I do not understand this question, sorry. thanks, greg k-h
