qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH 8/9] dev-serial: fix FTDI_GET_MDM_ST response


From: Jason Andryuk
Subject: Re: [PATCH 8/9] dev-serial: fix FTDI_GET_MDM_ST response
Date: Tue, 27 Oct 2020 09:30:36 -0400

On Tue, Oct 27, 2020 at 9:18 AM Mark Cave-Ayland
<mark.cave-ayland@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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]