Hi Johan,

You're only replying to me instead of replying to "all" so that the USB
mailing list is CCed. We don't do kernel development in private so
please make sure that your mails do not drop the list from CC.

I've added linux-usb@vger.kernel.org back on CC in my replies.

OK.  Now I see why my posts were not showing up.

Look for the set-line-request control request:

        bmRequestType   0x21
        bRequest        0x20    (SET_LINE_REQUEST)
        wValue          0
        wIndex          0
        wLength         7

the data stage should contain the corresponding 7 bytes of request data
for 110/cs7/parenb:

        d5 0e 00 80 00 02 07

Windows wireshark  URB_CONTROL_OUT packets
using putty set to at 110 baud 7E1

The windows usb captures have these 7 bytes for 110 baud:
           a8 a6 01 80 00 02 07

and these 7 bytes for 9600 baud:
           80 25 00 00 00 02 07   0x2580 = 9600

--------------------------------------------------------------------
Linux wireshark URB_CONTROL_OUT packet
using stty 110 evenp

usb capture for 110 baud 7E1
            d5 0e 00 80 00 02 07

I tried hard coding the first four 110 baud bytes into buf[0] - buf[3]
in the divisor subroutine and
110 baud work fine.  Possible problem in the divisor routine?

Thank you.

where the first four bytes encodes the baud rate (either directly or as
for 110 baud using divisors, see the code for details).

I'm afraid I don't have time to be reverse-engineering this myself, but
if you manage to find a difference in how the Windows driver configures
your device we may be able to figure out how to get 110 baud working.

Johan