On Mon, Feb 21, 2022 at 03:08:43PM +0000, embedded (VIVAVIS AG) wrote: > Hi, > thanks for the suggestion. > > > > > Hi, > > > > there seems to be a problem with the ftdi_sio driver in conjunction > > > > with an FT2232C and changing the baud rate. > > > > This behavior is observable at least on linux 4.19.190. > > > > You need to reproduce any issues you have with a more recent kernel such as 5.16. > Unfortunately, I cannot use a more recent kernel due to restrictions > with the development environment I am using. I did compare the code of > the ftdi_sio driver in version 4.19.190 with code included in a more > recent kernel release. I did not spot any fundamental changes that would > suggest that the problem was fixed. Then you're on your own, sorry. Perhaps you can bring it up with FTDI in case it is a known firmware issue. > > > > I verified that the driver does in fact ask the hardware if it's tx > > > > buffer is empty when the hardware status is reported. > > > > How exactly did you verify that? > I checked the code of the ftdi_sio driver, which captures the state of > the tx empty flag that is reported by the IC every time a specific USB > message is sent to it. Yeah, the driver supports that, but did you make sure that that function is actually called *before* changing the baud rate when you observe the problem? Note that it is also called during close. You need to trace the calls (or USB requests) to make sure that what you think is happening is indeed happening. The missing TCSADRAIN in your test program is an example of why that is needed. > > Unless you use TCSADRAIN (or TCSAFLUSH) the driver is not supposed > > to wait for the outgoing buffer to drain. > > > > Please confirm if changing this fixes the problem you're seeing. > I can still observe the same behavior, even after changing the calls > to tcsetattr to use TCSADRAIN instead of TCSANOW. The last byte of a > transfer is still being shifted out with the wrong baud rate. > Is there anything else that can be done in software to possibly > prevent this behavior? If you can reproduce this on a recent mainline kernel and show that it is indeed a driver or firmware issue, perhaps we can try to find a way to work around it. Good luck! Johan
