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@xxxxxxxxxxxxxxx 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
