pl2303.c 110 baud not working

pl2303.c 110 baud not working

[Joe Abbott]

Got redirected here by GKH email-bot.

My message to him was:
I have an ASR33 teletype that I'm trying to communicate with using a
PL2303 based Benfei USB serial adapter.  The ASR requires 110 baud 7E1
and it appears that the driver is defaulting to 9600 baud. (possibly
because the baud_sup array doesn't contain 110?)  I've tried adding
110 to the array and recompiling but that doesn't seem to help. I did
have to comment out the '/ SPDX-License-Identifier: GPL-2.0' line in
pl2303.c to get it to compile.

The windows driver works so the hardware is capable.

I must be missing something.  Any help appreciated.

Running Mint 19.3 64-bit.

I'm using stty to set baud rate like this:
stty 110 cs7 evenp -F /dev/ttyUSB0
stty reports that 110 is in use when I:
stty -F /dev/ttyUSB0

Oscope shows 150 and above changing (didn't try 75) but 110 reverts to
9600 (mentioned in pl2303.c file).

Also tried putty.

dmesg:
[ 3990.294929] usb 6-1: new full-speed USB device number 13 using uhci_hcd
[ 3990.479021] usb 6-1: New USB device found, idVendor=067b,
idProduct=2303, bcdDevice= 3.00
[ 3990.479028] usb 6-1: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[ 3990.479032] usb 6-1: Product: USB-Serial Controller
[ 3990.479036] usb 6-1: Manufacturer: Prolific Technology Inc.
[ 3990.481075] pl2303 6-1:1.0: pl2303 converter detected
[ 3990.494144] usb 6-1: pl2303 converter now attached to ttyUSB0


Here is lsusb:
Bus 002 Device 002: ID 0bda:0158 Realtek Semiconductor Corp. USB 2.0
multicard reader
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 007 Device 002: ID 046d:c00e Logitech, Inc. M-BJ58/M-BJ69 Optical
Wheel Mouse
Bus 007 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 006 Device 009: ID 067b:2303 Prolific Technology, Inc. PL2303 Serial Port
Bus 006 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 005 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 001 Device 002: ID 04f2:b027 Chicony Electronics Co., Ltd Gateway
USB 2.0 Webcam
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub

Here's modinfo:
filename:
/lib/modules/5.0.0-32-generic/kernel/drivers/usb/serial/pl2303.ko
license:        GPL v2
description:    Prolific PL2303 USB to serial adaptor driver
srcversion:     4864FE101A0398064B5D9A8
alias:          usb:v0CAAp3001d*dc*dsc*dp*ic*isc*ip*in*
alias:          usb:v0B8Cp2303d*dc*dsc*dp*ic*isc*ip*in*
alias:          usb:v0B63p6530d*dc*dsc*dp*ic*isc*ip*in*
alias:          usb:v11ADp0001d*dc*dsc*dp*ic*isc*ip*in*
alias:          usb:v054Cp0437d*dc*dsc*dp*ic*isc*ip*in*
alias:          usb:v04B8p0522d*dc*dsc*dp*ic*isc*ip*in*
alias:          usb:v04B8p0521d*dc*dsc*dp*ic*isc*ip*in*
alias:          usb:v03F0p0956d*dc*dsc*dp*ic*isc*ip*in*
alias:          usb:v03F0p5039d*dc*dsc*dp*ic*isc*ip*in*
alias:          usb:v03F0p026Bd*dc*dsc*dp*ic*isc*ip*in*
alias:          usb:v03F0p3239d*dc*dsc*dp*ic*isc*ip*in*
alias:          usb:v03F0p3139d*dc*dsc*dp*ic*isc*ip*in*
alias:          usb:v03F0p4439d*dc*dsc*dp*ic*isc*ip*in*
alias:          usb:v03F0p0B39d*dc*dsc*dp*ic*isc*ip*in*
alias:          usb:v03F0p0183d*dc*dsc*dp*ic*isc*ip*in*
alias:          usb:v03F0p0F7Fd*dc*dsc*dp*ic*isc*ip*in*
alias:          usb:v03F0p4349d*dc*dsc*dp*ic*isc*ip*in*
alias:          usb:v03F0p3524d*dc*dsc*dp*ic*isc*ip*in*
alias:          usb:v5372p2303d*dc*dsc*dp*ic*isc*ip*in*
alias:          usb:v05ADp0FBAd*dc*dsc*dp*ic*isc*ip*in*
alias:          usb:v07AAp002Ad*dc*dsc*dp*ic*isc*ip*in*
alias:          usb:v11F6p2001d*dc*dsc*dp*ic*isc*ip*in*
alias:          usb:v058Fp9720d*dc*dsc*dp*ic*isc*ip*in*
alias:          usb:v050Dp0257d*dc*dsc*dp*ic*isc*ip*in*
alias:          usb:v0731p2003d*dc*dsc*dp*ic*isc*ip*in*
alias:          usb:v0E55p110Bd*dc*dsc*dp*ic*isc*ip*in*
alias:          usb:v0413p2101d*dc*dsc*dp*ic*isc*ip*in*
alias:          usb:v079Bp0027d*dc*dsc*dp*ic*isc*ip*in*
alias:          usb:v10B5pAC70d*dc*dsc*dp*ic*isc*ip*in*
alias:          usb:v078Bp1234d*dc*dsc*dp*ic*isc*ip*in*
alias:          usb:v0745p0001d*dc*dsc*dp*ic*isc*ip*in*
alias:          usb:v04A5p4027d*dc*dsc*dp*ic*isc*ip*in*
alias:          usb:v11F5p0005d*dc*dsc*dp*ic*isc*ip*in*
alias:          usb:v11F5p0004d*dc*dsc*dp*ic*isc*ip*in*
alias:          usb:v11F5p0003d*dc*dsc*dp*ic*isc*ip*in*
alias:          usb:v11F5p0001d*dc*dsc*dp*ic*isc*ip*in*
alias:          usb:v11F7p02DFd*dc*dsc*dp*ic*isc*ip*in*
alias:          usb:v6189p2068d*dc*dsc*dp*ic*isc*ip*in*
alias:          usb:v0731p0528d*dc*dsc*dp*ic*isc*ip*in*
alias:          usb:v1453p4026d*dc*dsc*dp*ic*isc*ip*in*
alias:          usb:v2478p2008d*dc*dsc*dp*ic*isc*ip*in*
alias:          usb:v0584pB000d*dc*dsc*dp*ic*isc*ip*in*
alias:          usb:v0DF7p0620d*dc*dsc*dp*ic*isc*ip*in*
alias:          usb:v0EBAp2080d*dc*dsc*dp*ic*isc*ip*in*
alias:          usb:v0EBAp1080d*dc*dsc*dp*ic*isc*ip*in*
alias:          usb:v056Ep5004d*dc*dsc*dp*ic*isc*ip*in*
alias:          usb:v056Ep5003d*dc*dsc*dp*ic*isc*ip*in*
alias:          usb:v0547p2008d*dc*dsc*dp*ic*isc*ip*in*
alias:          usb:v0557p2118d*dc*dsc*dp*ic*isc*ip*in*
alias:          usb:v0557p2022d*dc*dsc*dp*ic*isc*ip*in*
alias:          usb:v0557p2021d*dc*dsc*dp*ic*isc*ip*in*
alias:          usb:v0557p2008d*dc*dsc*dp*ic*isc*ip*in*
alias:          usb:v04BBp0A0Ed*dc*dsc*dp*ic*isc*ip*in*
alias:          usb:v04BBp0A03d*dc*dsc*dp*ic*isc*ip*in*
alias:          usb:v067Bp23F3d*dc*dsc*dp*ic*isc*ip*in*
alias:          usb:v067Bp23E3d*dc*dsc*dp*ic*isc*ip*in*
alias:          usb:v067Bp23D3d*dc*dsc*dp*ic*isc*ip*in*
alias:          usb:v067Bp23C3d*dc*dsc*dp*ic*isc*ip*in*
alias:          usb:v067Bp23B3d*dc*dsc*dp*ic*isc*ip*in*
alias:          usb:v067Bp23A3d*dc*dsc*dp*ic*isc*ip*in*
alias:          usb:v067Bp2304d*dc*dsc*dp*ic*isc*ip*in*
alias:          usb:v067BpE1F1d*dc*dsc*dp*ic*isc*ip*in*
alias:          usb:v067Bp0307d*dc*dsc*dp*ic*isc*ip*in*
alias:          usb:v067Bp331Ad*dc*dsc*dp*ic*isc*ip*in*
alias:          usb:v067Bp0609d*dc*dsc*dp*ic*isc*ip*in*
alias:          usb:v067Bp0612d*dc*dsc*dp*ic*isc*ip*in*
alias:          usb:v067Bp0611d*dc*dsc*dp*ic*isc*ip*in*
alias:          usb:v067BpAAA0d*dc*dsc*dp*ic*isc*ip*in*
alias:          usb:v067BpAAA8d*dc*dsc*dp*ic*isc*ip*in*
alias:          usb:v067BpAAA2d*dc*dsc*dp*ic*isc*ip*in*
alias:          usb:v067Bp1234d*dc*dsc*dp*ic*isc*ip*in*
alias:          usb:v067Bp04BBd*dc*dsc*dp*ic*isc*ip*in*
alias:          usb:v067Bp2303d*dc*dsc*dp*ic*isc*ip*in*
depends:        usbserial
retpoline:      Y
name:           pl2303
vermagic:       5.0.0-32-generic SMP mod_unload

RE: pl2303.c 110 baud not working

[David Laight]

From: Joe Abbott
> Sent: 07 January 2021 21:06
> My message to him was:
> I have an ASR33 teletype that I'm trying to communicate with using a
> PL2303 based Benfei USB serial adapter.  The ASR requires 110 baud 7E1
...

I believe you'll also need either 1.5 or 2 stop bits (can't remember
which) and delays (usually 0 bytes) after CR (and probably LF).

Using an ASR33 with 'remote echo' is a bit like trying to talk
on a transatlantic phone line with broken echo cancellation.
Especially if the 100 baud link is being carried over acoustically
coupled modems (remember those?).

	David

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)

Re: pl2303.c 110 baud not working

[Johan Hovold]

On Thu, Jan 07, 2021 at 03:06:07PM -0600, Joe Abbott wrote:
> Got redirected here by GKH email-bot.
> 
> My message to him was:
> I have an ASR33 teletype that I'm trying to communicate with using a
> PL2303 based Benfei USB serial adapter.  The ASR requires 110 baud 7E1
> and it appears that the driver is defaulting to 9600 baud. (possibly
> because the baud_sup array doesn't contain 110?)  I've tried adding
> 110 to the array and recompiling but that doesn't seem to help. I did
> have to comment out the '/ SPDX-License-Identifier: GPL-2.0' line in
> pl2303.c to get it to compile.

No, you don't need to add 110 to the baud_sup array as 110 baud is set
using divisors (i.e. pl2303_encode_baud_rate_divisor()).

> The windows driver works so the hardware is capable.
> 
> I must be missing something.  Any help appreciated.
> 
> Running Mint 19.3 64-bit.
> 
> I'm using stty to set baud rate like this:
> stty 110 cs7 evenp -F /dev/ttyUSB0
> stty reports that 110 is in use when I:
> stty -F /dev/ttyUSB0
> 
> Oscope shows 150 and above changing (didn't try 75) but 110 reverts to
> 9600 (mentioned in pl2303.c file).

I just verified using a logic analyser that 110 baud works just fine
here (with even parity too) using a PL2303 HXD.

Not sure what kernel version you're on, but this should have been
supported since at least around 2015 (and I think we backported the
corresponding fix of the divisor algorithm to earlier kernels).

Try a recent mainline kernel or enable dynamic debugging and make sure
the line request is sent correctly (110 cs7 parenb):

	pl2303_set_line_request - d5 0e 00 80 00 02 07

If there's some difference in how your device encodes baud rates you may
be able to compare that with what the Windows driver uses by tracing the
USB packets.

Johan

Re: pl2303.c 110 baud not working

[Johan Hovold]

Please keep the USB list on CC.

On Fri, Jan 08, 2021 at 08:02:36AM -0600, Joe Abbott wrote:
> Thanks for the reply.
> 
> kernel version is 5.0.0-32-generic.  I've restored pl2303.ko to original.

5.0 should work as well.

> Chip version is PL2303TA.

And I believe that one is supposed to be compatible with HXD.

> When I loopback rs232 to pc at 150 baud it looks normal.  After
> setting to 110 baud it returns at a much higher rate and scope trace looks
> the same as when set to 9600 baud.
>
> Setting up debug might be beyond my abilities unless I could find a good
> how-to that I could follow.

You can either use debugfs:

	echo module pl2303 +p > /sys/kernel/debug/dynamic_debug/control

or provide an argument to modprobe:

	modprobe pl2303 dyndbg==p

Then just check demsg after calling stty (110 evenp).

> I'll look into capturing some windows packets at 110 and 9600.

Sounds good.

Johan

Re: pl2303.c 110 baud not working

[Johan Hovold]

On Sat, Jan 09, 2021 at 08:26:26AM -0600, Joe Abbott wrote:
> Hi Johan,
> 
> > Please keep the USB list on CC.
> I'm sorry, I don't know what you mean.

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.

> Here's dmesg after debug turned on and 'stty 110 cs7 parenb evenp -F
> /dev/ttyUSB0':
> [  315.112142] pl2303 ttyUSB0: pl2303_set_control_lines - 03
> [  315.115032] pl2303 ttyUSB0: pl2303_get_line_request - 80 25 00 00 00 00 08
> [  315.115038] pl2303 ttyUSB0: data bits = 7
> [  315.115041] pl2303 ttyUSB0: baud requested = 110
> [  315.115045] pl2303 ttyUSB0: baud set = 110
> [  315.115048] pl2303 ttyUSB0: stop bits = 1
> [  315.115051] pl2303 ttyUSB0: parity = even
> [  315.116032] pl2303 ttyUSB0: pl2303_set_line_request - d5 0e 00 80 00 02 07

So as expected, your 5.0 Mint kernel behaves just like mainline:

	pl2303_set_line_request - d5 0e 00 80 00 02 07

> [  315.116037] pl2303 6-1:1.0: pl2303_vendor_write - [0000] = 00
> 
> I have some windows wireshark usb captures for 110 and 9600 taken
> while using putty.
> I don't know how to interpret them.  What is the best way to send them to you?

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

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

Re: pl2303.c 110 baud not working

[Joe Abbott]

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

Re: pl2303.c 110 baud not working

[Johan Hovold]

On Sun, Jan 10, 2021 at 04:15:41PM -0600, Joe Abbott wrote:

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

Interesting...

> 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?

Or rather a new feature which do not yet support (or understand).

I tried hardcoding the same request with a HXD and it doesn't give me
110 baud. Instead the unsupported bits appears to be ignored and the
current divisor algorithm is applied so that

	a8 a6 01 80 00 02 07

gives the same result as if

	a8 06 00 80 00 02 07

had been requested (~35720 baud).

So in any case, we'd need to key this off of the device type.

I noticed that

	12000000 / 0x1a6a8 ~= 110.9

Possibly just a coincidence, especially as 0x1aa22 would be closer
match. But perhaps you can try a few more rates not in baud_sup and see
if you can figure it out.

Johan

Re: pl2303.c 110 baud not working

[Joe Abbott]

 Sorry it's been so long.  Busy.
 >
 > So in any case, we'd need to key this off of the device type.
 >
 Yes, key off type as I can't find the relationship.  Windows
 uses a8 a6 01 80 02 07  for any request near 110  and switches
 to direct encode for anything near 75 or 150.

 > I noticed that
 >
 >         12000000 / 0x1a6a8 ~= 110.9
 >
 > Possibly just a coincidence, especially as 0x1aa22 would be closer
 > match. But perhaps you can try a few more rates not in baud_sup and see
 > if you can figure it out.

 Coincidence. 0x01aa22 doesn't work. Not even close.

 I had to give up.  Too many other things to do and hard coding
 is working for me.

 Thanks for your help anyway.

 Joe

Re: pl2303.c 110 baud not working

[Johan Hovold]

On Sat, Jan 30, 2021 at 05:30:15AM -0600, Joe Abbott wrote:
>  Sorry it's been so long.  Busy.

No worries.

>  > So in any case, we'd need to key this off of the device type.
>  >
>  Yes, key off type as I can't find the relationship.  Windows
>  uses a8 a6 01 80 02 07  for any request near 110  and switches
>  to direct encode for anything near 75 or 150.

Ok, thanks for checking.

>  > I noticed that
>  >
>  >         12000000 / 0x1a6a8 ~= 110.9
>  >
>  > Possibly just a coincidence, especially as 0x1aa22 would be closer
>  > match. But perhaps you can try a few more rates not in baud_sup and see
>  > if you can figure it out.
> 
>  Coincidence. 0x01aa22 doesn't work. Not even close.
> 
>  I had to give up.  Too many other things to do and hard coding
>  is working for me.

I fully understand. Let me check with Prolific and see if they are
willing to shed some light on this.

Johan