On Tue, Oct 27, 2020 at 9:18 AM Mark Cave-Ayland <mark.cave-ayl...@ilande.co.uk> wrote: > > I spent a bit of time this morning doing some further tests on Linux using 2 > machines > and a test program to check CTS and usbmon: > > usbmon when adapter unplugged: > ffff95a4bf2dd300 2366831506 S Ci:4:004:0 s c0 05 0000 0000 0002 2 < > ffff95a4bf2dd300 2366831607 C Ci:4:004:0 0 2 = 0160 > > usbmon when adapter plugged in and remote connected to minicom: > ffff95a4452a79c0 2457273895 S Ci:4:004:0 s c0 05 0000 0000 0002 2 < > ffff95a4452a79c0 2457274057 C Ci:4:004:0 0 2 = 3160 > > It seems I made a mistake here since the response is interpreted as 2 bytes > rather > than a single little-endian word: with CTS asserted on the remote the first > byte is > 0x31 == FTDI_CTS | FTDI_DSR | 1, whilst the 2nd byte is 0x60 == FTDI_THRE | > FTDI_TEMT > which matches the existing QEMU code rather than the comments in ftdi_sio.h. > > So sorry for the noise: I'll drop this patch from the series and post a v2 > shortly.
No worries. Thanks for investigating. (I had the thought that maybe reserve bit 0 differentiates one and two byte responses? Bit 0 clear indicates a 1-byte response and set indicates a 2 bit response. But I'm just guessing.) Regards, Jason