Re: [PATCH 06/13] USB: serial: ch341: fix initial line settings

2016-12-20 Thread Russell Senior 
On Tue, Dec 20, 2016 at 8:07 AM, Johan Hovold  wrote:

> Perhaps we should determine what else is working or broken first,
> though.
>
> Russel, could you test if break-signalling works, and if the
> modem-control signals (DTR/RTS) are asserted at open? Do you get any
> interrupts when the modem-status changes (e.g. remote end hangs up --
> there should be debug messages)?

Which version(s) would you like tested?
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 06/13] USB: serial: ch341: fix initial line settings

2016-12-20 Thread Russell Senior 
On Tue, Dec 20, 2016 at 7:52 AM, Johan Hovold  wrote:
> On Tue, Dec 20, 2016 at 07:31:55AM -0800, Russell Senior wrote:

>> Not sure what the complaint about keys is about, I had not seen that
>> before.
>
> Related to module signing, not sure why you only see it with the vendor
> driver. Did you apply it to my usb-next branch or Greg's?

Yours.
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 06/13] USB: serial: ch341: fix initial line settings

2016-12-20 Thread Russell Senior 
On Tue, Dec 20, 2016 at 1:13 AM, Johan Hovold  wrote:
> Perhaps you could give the attached vendor driver a quick spin just to
> confirm that? It's a rebased version against usb-next.

This is plain jane usb-next with your vendor patch, which I applied in
a local branch:

 1-gfadd29d:

Dec 20 07:18:36 willard kernel: PKCS#7 signature not signed with a trusted key
Dec 20 07:18:36 willard kernel: ch341: module verification failed:
signature and/or required key missing - tainting kernel
Dec 20 07:18:36 willard kernel: usbcore: registered new interface driver ch341
Dec 20 07:18:36 willard kernel: usbserial: USB Serial support
registered for ch34x
Dec 20 07:18:44 willard kernel: usb 6-2: new full-speed USB device
number 12 using uhci_hcd
Dec 20 07:18:44 willard kernel: usb 6-2: New USB device found,
idVendor=1a86, idProduct=7523
Dec 20 07:18:44 willard kernel: usb 6-2: New USB device strings:
Mfr=0, Product=2, SerialNumber=0
Dec 20 07:18:44 willard kernel: usb 6-2: Product: USB2.0-Ser!
Dec 20 07:18:44 willard kernel: ch341 6-2:1.0: ch34x converter detected
Dec 20 07:18:44 willard kernel: [ cut here ]
Dec 20 07:18:44 willard kernel: WARNING: CPU: 1 PID: 30168 at
/home/russell/src/usb-serial/drivers/usb/core/hcd.c:1584
usb_hcd_map_urb_for_dma+0x382/0x560
Dec 20 07:18:44 willard kernel: transfer buffer not dma capable
Dec 20 07:18:44 willard kernel: Modules linked in: ch341(E) ntfs msdos
pl2303 usbserial bnep arc4 iwldvm mac80211 btusb btrtl btbcm btintel
bluetooth snd_hda_codec_hdmi uvcvideo snd_hda_codec_conexant
snd_hda_codec_generic videobuf2_vmalloc videobuf2_memops
videobuf2_v4l2 videobuf2_core videodev iwlwifi snd_hda_inte
l coretemp media kvm_intel snd_hda_codec snd_hda_core kvm
thinkpad_acpi snd_hwdep mei_me mei nvram cfg80211 snd_pcm snd_seq_midi
snd_seq_midi_event snd_rawmidi snd_seq snd_seq_device
Dec 20 07:18:44 willard kernel:  snd_timer irqbypass snd joydev input_leds
Dec 20 07:18:44 willard kernel:  serio_raw
Dec 20 07:18:44 willard kernel:  lpc_ich soundcore autofs4 amdkfd
amd_iommu_v2 radeon i915 i2c_algo_bit ttm e1000e drm_kms_helper
psmouse syscopyarea firewire_ohci sysfillrect sysimgblt fb_sys_fops
ahci libahci firewire_core drm crc_itu_t ptp wmi video pps_core [last
unloaded: ch341]
Dec 20 07:18:44 willard kernel: CPU: 1 PID: 30168 Comm: kworker/1:0
Tainted: GE   4.9.0-rc2-2016-12-16-00013-gc510871 #1
Dec 20 07:18:44 willard kernel: Hardware name: LENOVO 406227U/406227U,
BIOS 7VET66WW (2.16 ) 04/22/2009
Dec 20 07:18:44 willard kernel: Workqueue: usb_hub_wq hub_event
Dec 20 07:18:44 willard kernel:  a51f89e4f3a8 ae3e8ec3
a51f89e4f3f8 
Dec 20 07:18:44 willard kernel:  a51f89e4f3e8 ae07f90b
063033791ae0 8ae139fe23c0
Dec 20 07:18:44 willard kernel:   0240
0002 8ae11a80a800
Dec 20 07:18:44 willard kernel: Call Trace:
Dec 20 07:18:44 willard kernel:  [] dump_stack+0x63/0x90
Dec 20 07:18:44 willard kernel:  [] __warn+0xcb/0xf0
Dec 20 07:18:44 willard kernel:  []
warn_slowpath_fmt+0x5f/0x80
Dec 20 07:18:44 willard kernel:  []
usb_hcd_map_urb_for_dma+0x382/0x560
Dec 20 07:18:44 willard kernel:  []
usb_hcd_submit_urb+0x1d2/0xac0
Dec 20 07:18:44 willard kernel:  [] ? vprintk_emit+0x2ea/0x4d0
Dec 20 07:18:44 willard kernel:  [] usb_submit_urb+0x2eb/0x570
Dec 20 07:18:44 willard kernel:  []
usb_start_wait_urb+0x6e/0x170
Dec 20 07:18:44 willard kernel:  [] usb_control_msg+0xdc/0x130
Dec 20 07:18:44 willard kernel:  []
ch34x_attach+0x1d7/0x2b0 [ch341]
Dec 20 07:18:44 willard kernel:  []
usb_serial_probe+0xf10/0x1170 [usbserial]
Dec 20 07:18:44 willard kernel:  [] ?
ida_simple_get+0x98/0x100
Dec 20 07:18:44 willard kernel:  [] ?
kernfs_activate+0x7a/0xe0
Dec 20 07:18:44 willard kernel:  [] ?
__pm_runtime_set_status+0x1e0/0x2a0
Dec 20 07:18:44 willard kernel:  []
usb_probe_interface+0x153/0x2f0
Dec 20 07:18:44 willard kernel:  []
driver_probe_device+0x224/0x430
Dec 20 07:18:44 willard kernel:  []
__device_attach_driver+0x8c/0x100
Dec 20 07:18:44 willard kernel:  [] ?
__driver_attach+0xf0/0xf0
Dec 20 07:18:44 willard kernel:  [] bus_for_each_drv+0x67/0xb0
Dec 20 07:18:44 willard kernel:  [] __device_attach+0xdd/0x160
Dec 20 07:18:44 willard kernel:  []
device_initial_probe+0x13/0x20
Dec 20 07:18:44 willard kernel:  [] bus_probe_device+0x92/0xa0
Dec 20 07:18:44 willard kernel:  [] device_add+0x3fd/0x670
Dec 20 07:18:44 willard kernel:  []
usb_set_configuration+0x529/0x8d0
Dec 20 07:18:44 willard kernel:  [] generic_probe+0x2e/0x80
Dec 20 07:18:44 willard kernel:  [] usb_probe_device+0x2e/0x70
Dec 20 07:18:44 willard kernel:  []
driver_probe_device+0x224/0x430
Dec 20 07:18:44 willard kernel:  []
__device_attach_driver+0x8c/0x100
Dec 20 07:18:44 willard kernel:  [] ?
__driver_attach+0xf0/0xf0
Dec 20 07:18:44 willard kernel:  [] bus_for_each_drv+0x67/0xb0
Dec 20 07:18:44 willard kernel:  [] __device_attach+0xdd/0x160
Dec 20 07:18:44 willard kernel:  []
device_initial_probe+0x13/0x

Re: [PATCH 06/13] USB: serial: ch341: fix initial line settings

2016-12-20 Thread Russell Senior 
> I'm not sure what device we're dealing with here, but it seems it would
> not be supported by the vendor (whose version of this driver also uses
> the init-command).
>
> Perhaps you could give the attached vendor driver a quick spin just to
> confirm that? It's a rebased version against usb-next.
>
> I've also pushed a commit that tries to dump the registers differently
> (reading together with register 0x25):
>
> 3baa1eff4245 ("dbg: ch341: dump registers differently")

00019-g3baa1ef:

Dec 20 04:30:50 willard kernel: usbcore: registered new interface driver ch341
Dec 20 04:30:50 willard kernel: usbserial: USB Serial support
registered for ch341-uart
Dec 20 04:31:14 willard kernel: usb 6-2: new full-speed USB device
number 11 using uhci_hcd
Dec 20 04:31:14 willard kernel: usb 6-2: New USB device found,
idVendor=1a86, idProduct=7523
Dec 20 04:31:14 willard kernel: usb 6-2: New USB device strings:
Mfr=0, Product=2, SerialNumber=0
Dec 20 04:31:14 willard kernel: usb 6-2: Product: USB2.0-Ser!
Dec 20 04:31:14 willard kernel: ch341 6-2:1.0: ch341-uart converter detected
Dec 20 04:31:14 willard kernel: ch341 6-2:1.0: [00] = 00
Dec 20 04:31:14 willard kernel: ch341 6-2:1.0: [01] = 00
Dec 20 04:31:14 willard kernel: ch341 6-2:1.0: [02] = 00
Dec 20 04:31:14 willard kernel: ch341 6-2:1.0: [03] = 00
Dec 20 04:31:14 willard kernel: ch341 6-2:1.0: [04] = 00
Dec 20 04:31:14 willard kernel: ch341 6-2:1.0: [05] = 00
Dec 20 04:31:14 willard kernel: ch341 6-2:1.0: [06] = 00
Dec 20 04:31:14 willard kernel: ch341 6-2:1.0: [07] = 00
Dec 20 04:31:14 willard kernel: ch341 6-2:1.0: [08] = 00
Dec 20 04:31:14 willard kernel: ch341 6-2:1.0: [09] = 00
Dec 20 04:31:14 willard kernel: ch341 6-2:1.0: [0a] = 00
Dec 20 04:31:14 willard kernel: ch341 6-2:1.0: [0b] = 00
Dec 20 04:31:14 willard kernel: ch341 6-2:1.0: [0c] = 00
Dec 20 04:31:14 willard kernel: ch341 6-2:1.0: [0d] = 00
Dec 20 04:31:14 willard kernel: ch341 6-2:1.0: [0e] = 00
Dec 20 04:31:14 willard kernel: ch341 6-2:1.0: [0f] = 00
Dec 20 04:31:14 willard kernel: ch341 6-2:1.0: [10] = 00
Dec 20 04:31:14 willard kernel: ch341 6-2:1.0: [11] = 00
Dec 20 04:31:14 willard kernel: ch341 6-2:1.0: [12] = 00
Dec 20 04:31:14 willard kernel: ch341 6-2:1.0: [13] = 00
Dec 20 04:31:14 willard kernel: ch341 6-2:1.0: [14] = 00
Dec 20 04:31:14 willard kernel: ch341 6-2:1.0: [15] = 00
Dec 20 04:31:14 willard kernel: ch341 6-2:1.0: [16] = 00
Dec 20 04:31:14 willard kernel: ch341 6-2:1.0: [17] = 00
Dec 20 04:31:14 willard kernel: ch341 6-2:1.0: [18] = c3
Dec 20 04:31:14 willard kernel: ch341 6-2:1.0: [19] = 00
Dec 20 04:31:14 willard kernel: ch341 6-2:1.0: [1a] = 00
Dec 20 04:31:14 willard kernel: ch341 6-2:1.0: [1b] = 00
Dec 20 04:31:14 willard kernel: ch341 6-2:1.0: [1c] = 00
Dec 20 04:31:14 willard kernel: ch341 6-2:1.0: [1d] = 00
Dec 20 04:31:14 willard kernel: ch341 6-2:1.0: [1e] = 00
Dec 20 04:31:14 willard kernel: ch341 6-2:1.0: [1f] = 00
Dec 20 04:31:14 willard kernel: ch341 6-2:1.0: [20] = 00
Dec 20 04:31:14 willard kernel: ch341 6-2:1.0: [21] = 00
Dec 20 04:31:14 willard kernel: ch341 6-2:1.0: [22] = 00
Dec 20 04:31:14 willard kernel: ch341 6-2:1.0: [23] = 00
Dec 20 04:31:14 willard kernel: ch341 6-2:1.0: [24] = 00
Dec 20 04:31:14 willard kernel: ch341 6-2:1.0: [25] = 00
Dec 20 04:31:14 willard kernel: ch341 6-2:1.0: [26] = 00
Dec 20 04:31:14 willard kernel: ch341 6-2:1.0: [27] = 00
Dec 20 04:31:14 willard kernel: ch341 6-2:1.0: [28] = 00
Dec 20 04:31:14 willard kernel: ch341 6-2:1.0: [29] = 00
Dec 20 04:31:14 willard kernel: ch341 6-2:1.0: [2a] = 00
Dec 20 04:31:14 willard kernel: ch341 6-2:1.0: [2b] = 00
Dec 20 04:31:14 willard kernel: ch341 6-2:1.0: [2c] = 00
Dec 20 04:31:14 willard kernel: ch341 6-2:1.0: [2d] = 00
Dec 20 04:31:14 willard kernel: ch341 6-2:1.0: [2e] = 00
Dec 20 04:31:14 willard kernel: ch341 6-2:1.0: [2f] = 00
Dec 20 04:31:14 willard kernel: ch341 6-2:1.0: init 0 0
Dec 20 04:31:14 willard kernel: ch341 6-2:1.0: [00] = 00
Dec 20 04:31:14 willard kernel: ch341 6-2:1.0: [01] = 00
Dec 20 04:31:14 willard kernel: ch341 6-2:1.0: [02] = 00
Dec 20 04:31:14 willard kernel: ch341 6-2:1.0: [03] = 00
Dec 20 04:31:14 willard kernel: ch341 6-2:1.0: [04] = 00
Dec 20 04:31:14 willard kernel: ch341 6-2:1.0: [05] = 00
Dec 20 04:31:14 willard kernel: ch341 6-2:1.0: [06] = 00
Dec 20 04:31:14 willard kernel: ch341 6-2:1.0: [07] = 00
Dec 20 04:31:14 willard kernel: ch341 6-2:1.0: [08] = 00
Dec 20 04:31:14 willard kernel: ch341 6-2:1.0: [09] = 00
Dec 20 04:31:14 willard kernel: ch341 6-2:1.0: [0a] = 00
Dec 20 04:31:14 willard kernel: ch341 6-2:1.0: [0b] = 00
Dec 20 04:31:14 willard kernel: ch341 6-2:1.0: [0c] = 00
Dec 20 04:31:14 willard kernel: ch341 6-2:1.0: [0d] = 00
Dec 20 04:31:14 willard kernel: ch341 6-2:1.0: [0e] = 00
Dec 20 04:31:14 willard kernel: ch341 6-2:1.0: [0f] = 00
Dec 20 04:31:14 willard kernel: ch341 6-2:1.0: [10] = 00
Dec 20 04:31:14 willard kernel: ch341 6-2:1.0: [11] = 00
Dec 20 04:31:14 willard kernel: ch341 6-2:1.0: [12] = 00
Dec 20 04:31:14 willard kernel: c

Re: [PATCH 06/13] USB: serial: ch341: fix initial line settings

2016-12-19 Thread Russell Senior 
>> Apart from the two additional tests mentioned above, can you also
>> provide a log from when connecting the device using the following commit
>> that I just pushed to the ch341 branch:
>>
>> f341ee36198d ("dbg: ch341: add register dumps to probe")
>>
>> which provides dumps of the register settings during initialisation.
>> (Make sure ch341 dynamic debugging is not enabled to avoid cluttering
>> the log.)
>
> I'll send this in a followup, need to rebuild.

00018-gf341ee3:

Dec 19 13:51:13 willard kernel: usbcore: registered new interface driver ch341
Dec 19 13:51:13 willard kernel: usbserial: USB Serial support
registered for ch341-uart
Dec 19 13:51:23 willard kernel: usb 6-2: new full-speed USB device
number 10 using uhci_hcd
Dec 19 13:51:23 willard kernel: usb 6-2: New USB device found,
idVendor=1a86, idProduct=7523
Dec 19 13:51:23 willard kernel: usb 6-2: New USB device strings:
Mfr=0, Product=2, SerialNumber=0
Dec 19 13:51:23 willard kernel: usb 6-2: Product: USB2.0-Ser!
Dec 19 13:51:23 willard kernel: ch341 6-2:1.0: ch341-uart converter detected
Dec 19 13:51:23 willard kernel: ch341 6-2:1.0: [00] = 00
Dec 19 13:51:23 willard kernel: ch341 6-2:1.0: [01] = 00
Dec 19 13:51:23 willard kernel: ch341 6-2:1.0: [02] = 00
Dec 19 13:51:23 willard kernel: ch341 6-2:1.0: [03] = 00
Dec 19 13:51:23 willard kernel: ch341 6-2:1.0: [04] = 00
Dec 19 13:51:23 willard kernel: ch341 6-2:1.0: [05] = 00
Dec 19 13:51:23 willard kernel: ch341 6-2:1.0: [06] = 00
Dec 19 13:51:23 willard kernel: ch341 6-2:1.0: [07] = 00
Dec 19 13:51:23 willard kernel: ch341 6-2:1.0: [08] = 00
Dec 19 13:51:23 willard kernel: ch341 6-2:1.0: [09] = 00
Dec 19 13:51:23 willard kernel: ch341 6-2:1.0: [0a] = 00
Dec 19 13:51:23 willard kernel: ch341 6-2:1.0: [0b] = 00
Dec 19 13:51:23 willard kernel: ch341 6-2:1.0: [0c] = 00
Dec 19 13:51:23 willard kernel: ch341 6-2:1.0: [0d] = 00
Dec 19 13:51:23 willard kernel: ch341 6-2:1.0: [0e] = 00
Dec 19 13:51:23 willard kernel: ch341 6-2:1.0: [0f] = 00
Dec 19 13:51:23 willard kernel: ch341 6-2:1.0: [10] = 00
Dec 19 13:51:23 willard kernel: ch341 6-2:1.0: [11] = 00
Dec 19 13:51:23 willard kernel: ch341 6-2:1.0: [12] = 00
Dec 19 13:51:23 willard kernel: ch341 6-2:1.0: [13] = 00
Dec 19 13:51:23 willard kernel: ch341 6-2:1.0: [14] = 00
Dec 19 13:51:23 willard kernel: ch341 6-2:1.0: [15] = 00
Dec 19 13:51:23 willard kernel: ch341 6-2:1.0: [16] = 00
Dec 19 13:51:23 willard kernel: ch341 6-2:1.0: [17] = 00
Dec 19 13:51:23 willard kernel: ch341 6-2:1.0: [18] = 00
Dec 19 13:51:23 willard kernel: ch341 6-2:1.0: [19] = 00
Dec 19 13:51:23 willard kernel: ch341 6-2:1.0: [1a] = 00
Dec 19 13:51:23 willard kernel: ch341 6-2:1.0: [1b] = 00
Dec 19 13:51:23 willard kernel: ch341 6-2:1.0: [1c] = 00
Dec 19 13:51:23 willard kernel: ch341 6-2:1.0: [1d] = 00
Dec 19 13:51:23 willard kernel: ch341 6-2:1.0: [1e] = 00
Dec 19 13:51:23 willard kernel: ch341 6-2:1.0: [1f] = 00
Dec 19 13:51:23 willard kernel: ch341 6-2:1.0: [20] = 00
Dec 19 13:51:23 willard kernel: ch341 6-2:1.0: [21] = 00
Dec 19 13:51:23 willard kernel: ch341 6-2:1.0: [22] = 00
Dec 19 13:51:23 willard kernel: ch341 6-2:1.0: [23] = 00
Dec 19 13:51:23 willard kernel: ch341 6-2:1.0: [24] = 00
Dec 19 13:51:23 willard kernel: ch341 6-2:1.0: [25] = 00
Dec 19 13:51:23 willard kernel: ch341 6-2:1.0: [26] = 00
Dec 19 13:51:23 willard kernel: ch341 6-2:1.0: [27] = 00
Dec 19 13:51:23 willard kernel: ch341 6-2:1.0: [28] = 00
Dec 19 13:51:23 willard kernel: ch341 6-2:1.0: [29] = 00
Dec 19 13:51:23 willard kernel: ch341 6-2:1.0: [2a] = 00
Dec 19 13:51:23 willard kernel: ch341 6-2:1.0: [2b] = 00
Dec 19 13:51:23 willard kernel: ch341 6-2:1.0: [2c] = 00
Dec 19 13:51:23 willard kernel: ch341 6-2:1.0: [2d] = 00
Dec 19 13:51:23 willard kernel: ch341 6-2:1.0: [2e] = 00
Dec 19 13:51:23 willard kernel: ch341 6-2:1.0: [2f] = 00
Dec 19 13:51:23 willard kernel: ch341 6-2:1.0: init 0 0
Dec 19 13:51:23 willard kernel: ch341 6-2:1.0: [00] = 00
Dec 19 13:51:23 willard kernel: ch341 6-2:1.0: [01] = 00
Dec 19 13:51:23 willard kernel: ch341 6-2:1.0: [02] = 00
Dec 19 13:51:23 willard kernel: ch341 6-2:1.0: [03] = 00
Dec 19 13:51:23 willard kernel: ch341 6-2:1.0: [04] = 00
Dec 19 13:51:23 willard kernel: ch341 6-2:1.0: [05] = 00
Dec 19 13:51:23 willard kernel: ch341 6-2:1.0: [06] = 00
Dec 19 13:51:23 willard kernel: ch341 6-2:1.0: [07] = 00
Dec 19 13:51:23 willard kernel: ch341 6-2:1.0: [08] = 00
Dec 19 13:51:23 willard kernel: ch341 6-2:1.0: [09] = 00
Dec 19 13:51:23 willard kernel: ch341 6-2:1.0: [0a] = 00
Dec 19 13:51:23 willard kernel: ch341 6-2:1.0: [0b] = 00
Dec 19 13:51:23 willard kernel: ch341 6-2:1.0: [0c] = 00
Dec 19 13:51:23 willard kernel: ch341 6-2:1.0: [0d] = 00
Dec 19 13:51:23 willard kernel: ch341 6-2:1.0: [0e] = 00
Dec 19 13:51:23 willard kernel: ch341 6-2:1.0: [0f] = 00
Dec 19 13:51:23 willard kernel: ch341 6-2:1.0: [10] = 00
Dec 19 13:51:23 willard kernel: ch341 6-2:1.0: [11] = 00
Dec 19 13:51:23 willard kernel: ch341 6-2:1.0: [12] = 00
Dec 19 13:51:23 willard kernel: ch341 6-2:1.0:

Re: [PATCH 06/13] USB: serial: ch341: fix initial line settings

2016-12-19 Thread Russell Senior 
On Mon, Dec 19, 2016 at 2:58 AM, Johan Hovold  wrote:
> On Sat, Dec 17, 2016 at 03:27:43AM -0800, Russell Senior wrote:
>> All testing is with minicom.
>
> Thanks for this through report.
>
>> Starting with 00013-gc510871:
>>
>>   In 8-bit mode, interoperates correctly with pl2303.  Switching to
>> 5-bit mode on both sides (I get unicode boxes of indeterminate
>> values).  Switching back to 8-bit mode on both sides, I get correct
>> text out both sides.  Switching just the ch341 side back to 5-bit
>> mode, I get 0xff's out on the pl2303 side (still in 8-bit mode).  This
>> would seem to imply that byte-size changes are working on this
>> version.  Changing baud rate also works.
>
> Can you verify also what comes through in 5-bit mode is indeed what's
> expected (e.g. 'a' -> 0x01, 'b' -> 0x02, ...)?
>
> You can enable usb-serial debugging to get a log of what is received:
>
> modprobe usbserial dyndbg==p
>

Yes, it does seem that I'm getting the 5-bit truncation.  Here is an
excerpt from the prodigious logs, in this case sending a 'Z' from
pl2303 and receiving an 0x5a on the ch341.  The same sort of thing,
e.g. 'A' (0x41) from the ch341 lands as an 0x01 on the pl2303, 0x42 ->
0x02, etc.

Dec 19 08:22:53 willard kernel: tty ttyUSB0: serial_chars_in_buffer
Dec 19 08:22:53 willard kernel: ch341-uart ttyUSB0:
usb_serial_generic_chars_in_buffer - returns 0
Dec 19 08:22:53 willard kernel: tty ttyUSB0: serial_write_room
Dec 19 08:22:53 willard kernel: ch341-uart ttyUSB0:
usb_serial_generic_write_room - returns 4096
Dec 19 08:22:53 willard kernel: tty ttyUSB0: serial_tiocmget
Dec 19 08:22:53 willard kernel: tty ttyUSB0: serial_ioctl - cmd 0x5401
Dec 19 08:22:53 willard kernel: tty ttyUSB0: serial_chars_in_buffer
Dec 19 08:22:53 willard kernel: ch341-uart ttyUSB0:
usb_serial_generic_chars_in_buffer - returns 0
Dec 19 08:22:53 willard kernel: tty ttyUSB0: serial_write_room
Dec 19 08:22:53 willard kernel: ch341-uart ttyUSB0:
usb_serial_generic_write_room - returns 4096
Dec 19 08:22:53 willard kernel: tty ttyUSB1: serial_chars_in_buffer
Dec 19 08:22:53 willard kernel: pl2303 ttyUSB1:
usb_serial_generic_chars_in_buffer - returns 0
Dec 19 08:22:53 willard kernel: tty ttyUSB1: serial_write_room
Dec 19 08:22:53 willard kernel: pl2303 ttyUSB1:
usb_serial_generic_write_room - returns 4096
Dec 19 08:22:53 willard kernel: tty ttyUSB1: serial_tiocmget
Dec 19 08:22:53 willard kernel: tty ttyUSB1: serial_ioctl - cmd 0x5401
Dec 19 08:22:53 willard kernel: tty ttyUSB1: serial_chars_in_buffer
Dec 19 08:22:53 willard kernel: pl2303 ttyUSB1:
usb_serial_generic_chars_in_buffer - returns 0
Dec 19 08:22:53 willard kernel: tty ttyUSB1: serial_write_room
Dec 19 08:22:53 willard kernel: pl2303 ttyUSB1:
usb_serial_generic_write_room - returns 4096
Dec 19 08:22:53 willard kernel: tty ttyUSB1: serial_chars_in_buffer
Dec 19 08:22:53 willard kernel: pl2303 ttyUSB1:
usb_serial_generic_chars_in_buffer - returns 0
Dec 19 08:22:53 willard kernel: tty ttyUSB1: serial_write_room
Dec 19 08:22:53 willard kernel: pl2303 ttyUSB1:
usb_serial_generic_write_room - returns 4096
Dec 19 08:22:53 willard kernel: tty ttyUSB1: serial_write - 1 byte(s)
Dec 19 08:22:53 willard kernel: pl2303 ttyUSB1:
usb_serial_generic_write_start - length = 1, data = 5a
Dec 19 08:22:53 willard kernel: tty ttyUSB1: serial_tiocmget
Dec 19 08:22:53 willard kernel: tty ttyUSB1: serial_ioctl - cmd 0x5401
Dec 19 08:22:53 willard kernel: tty ttyUSB1: serial_chars_in_buffer
Dec 19 08:22:53 willard kernel: pl2303 ttyUSB1:
usb_serial_generic_chars_in_buffer - returns 1
Dec 19 08:22:53 willard kernel: tty ttyUSB1: serial_write_room
Dec 19 08:22:53 willard kernel: pl2303 ttyUSB1:
usb_serial_generic_write_room - returns 4096
Dec 19 08:22:53 willard kernel: ch341-uart ttyUSB0:
usb_serial_generic_read_bulk_callback - urb 1, len 1
Dec 19 08:22:53 willard kernel: ch341-uart ttyUSB0:
usb_serial_generic_read_bulk_callback - length = 1, data = 1a
Dec 19 08:22:53 willard kernel: ch341-uart ttyUSB0:
usb_serial_generic_submit_read_urb - urb 1
Dec 19 08:22:53 willard kernel: tty ttyUSB0: serial_chars_in_buffer
Dec 19 08:22:53 willard kernel: ch341-uart ttyUSB0:
usb_serial_generic_chars_in_buffer - returns 0
Dec 19 08:22:53 willard kernel: tty ttyUSB0: serial_write_room
Dec 19 08:22:53 willard kernel: ch341-uart ttyUSB0:
usb_serial_generic_write_room - returns 4096
Dec 19 08:22:53 willard kernel: tty ttyUSB0: serial_tiocmget
Dec 19 08:22:53 willard kernel: tty ttyUSB0: serial_ioctl - cmd 0x5401
Dec 19 08:22:53 willard kernel: tty ttyUSB0: serial_chars_in_buffer
Dec 19 08:22:53 willard kernel: ch341-uart ttyUSB0:
usb_serial_generic_chars_in_buffer - returns 0
Dec 19 08:22:53 willard kernel: tty ttyUSB0: serial_write_room
Dec 19 08:22:53 willard kernel: ch341-uart ttyUSB0:
usb_serial_generic_write_room - returns 4096


>> 00014-g7

Re: [PATCH 06/13] USB: serial: ch341: fix initial line settings

2016-12-17 Thread Russell Senior 
t anything else!


On Fri, Dec 16, 2016 at 9:30 AM, Johan Hovold  wrote:
> On Fri, Dec 16, 2016 at 05:13:50PM +0100, Johan Hovold wrote:
>> On Fri, Dec 16, 2016 at 08:04:18AM -0800, Russell Senior wrote:
>> > Sorry, I got distracted.  I'm back now.  Do you want me to test your
>> > 13 patch series?  And what is that on top of?
>>
>> Yes, please. It's against my usb-next branch.
>>
>> I'll send you a couple of diagnostics patches as well shortly.
>
> I ended up pushing a new branch, ch341 to my tree
>
> git://git.kernel.org/pub/scm/linux/kernel/git/johan/usb-serial.git
>
> which contains the full series as well as four debug patches (on top of
> usb-next).
>
> Could you first try and see if the series works with some register dumps
> enabled:
>
> 79e475a77796 dbg: ch341: add divisor and lcr debugging
>
> If that works, could you try the next commit and see if all still works
>
> ee5a27b51e95 dbg: ch341: enable rx timer
>
> Either way, could you also try the next commit which again tries to use
> the init-command for all devices:
>
> a06b45d910e3 dbg: ch341: use init for all devices
>
> and if that does not work, the final commit tries to use the init
> command but always use the chip default LCR:
>
> 6edc2830abe1 dbg: ch341: always use default LCR
>
> As you know there are, at least two levels of "working" here
>
> 1. Your device works and you can change baud rate, but you're
>stuck with 8N1
>
> 2. Changing LCR also works (e.g. switching back and forth
>between say 5N1 and 8N1 also works).
>
> When testing a new commit, always make sure to disconnect and reconnect
> the device first.
>
> Logs from all tests would be helpful (e.g. to see what effects the
> various commands has on the registers).
>
> Just let me know if you have any questions.
>
> Thanks,
> Johan
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 06/13] USB: serial: ch341: fix initial line settings

2016-12-16 Thread Russell Senior 
Sorry, I got distracted.  I'm back now.  Do you want me to test your
13 patch series?  And what is that on top of?

Thanks

On Fri, Dec 16, 2016 at 6:46 AM, Johan Hovold  wrote:
> On Fri, Dec 16, 2016 at 01:19:05PM +, Aidan Thornton wrote:
>> On Wed, Dec 14, 2016 at 3:28 PM, Johan Hovold  wrote:
>> > The ch341 driver is based on reverse-engineering and contains some bits
>> > which appear to be redundant and some which appear incompatible which
>> > certain devices.
>> >
>> > Specifically, some CH340 devices seem unable to change the initial line
>> > settings, which have so far been set to 5N1. Let's use a more reasonable
>> > 8N1 default instead.
>> >
>> > Note that we also need to set the ENABLE_RX bit or receive will be
>> > disabled after a reset during resume.
>>
>> Lost track a little of the testing, but I don't think you ever got
>> Russel to test whether this worked using a driver that tried to change
>> this through direct register writes which seem to be the only thing
>> that has any effect on this strange hardware variant. Would be a
>> little surprised if it didn't at this point - changing the line
>> settings that way after initialization certainly works well enough to
>> cause us all a headache.
>
> I believe he did test this against my usb-linus branch, which did not
> have your recent changes. IIRC both removing that first LCR write and
> changing it to 0xc3 worked, but maybe you're right and we only verified
> removing it.
>
> In the same setup, changing the word size after successful
> initialisation using direct register writes did not work however, and
> the device appeared stuck at 5N1 or 8N1 depending on if the initial 0x50
> LCR write was left in or not.
>
>> If so, I suggest it might be clearer to drop this patch altogether in
>> favour of patch 10 in the series, since the underlying problem is that
>> setting the baudrate and LCR register didn't work and patch 10 fixes
>> that.
>
> These two patches are definitely related, and I struggled a bit about
> how to order things as I wanted to find a way to backport this minimal
> change (from 5N1 to 8N1) without having to depend on the upcoming
> changes in 4.10 (your changes) as that may be enough to enable support
> in older kernels.
>
> I'll respin this, once we learn more about how those quirky devices
> work.
>
> Thanks,
> Johan
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: ch341

2016-12-12 Thread Russell Senior 
On Mon, Dec 12, 2016 at 10:19 AM, Johan Hovold  wrote:
> On Mon, Dec 12, 2016 at 08:03:03AM -0800, Russell Senior wrote:
>> On Mon, Dec 12, 2016 at 7:54 AM, Johan Hovold  wrote:
>> > On Mon, Dec 12, 2016 at 07:51:59AM -0800, Russell Senior wrote:
>> >> On Mon, Dec 12, 2016 at 7:40 AM, Johan Hovold  wrote:
>> >> > On Mon, Dec 12, 2016 at 07:09:34AM -0800, Russell Senior wrote:
>> >> >> On Mon, Dec 12, 2016 at 1:54 AM, Johan Hovold  wrote:
>> >> >>
>> >> >> > Ok, so maybe your device simply does not support changing the line
>> >> >> > settings more than once. That is, the initial settings chosen are 
>> >> >> > used
>> >> >> > until re-connected. This would seem to be in accordance with a 
>> >> >> > comment
>> >> >> > found in one of the out-of-tree drivers floating around (and which at
>> >> >> > least I hoped would no longer be an issue with the new way of 
>> >> >> > changing
>> >> >> > the settings).
>> >> >> >
>> >> >> > If you connect the ch340 you have in loopback mode, with the removed
>> >> >> > initial LCR write that fixed the 5-bit behaviour, can you get that
>> >> >> > behaviour back by setting 5-bit word size after opening the port? 
>> >> >> > (This
>> >> >> > was what I was going for with my original question above.).
>> >> >>
>> >> >> With minicom configured with 5N1 (that is, 5-bit mode), loopback looks
>> >> >> normal.  I type an 'a' and I get and 'a' back.  Likewise, I type an
>> >> >> 'A' and I get an 'A' back.  I used a saved .minicom.dfl file to
>> >> >> configure the port.
>> >> >
>> >> > Ok, so that seems to confirm the suspicion that changing settings after
>> >> > the initial configuration is failing (even though the device does indeed
>> >> > support 5-bit mode).
>> >> >
>> >> > Could you try to verify if that applies to the baud rate as well? That
>> >> > is, can you switch between say 9600 and 115200 after opening the port
>> >> > and verify that against the pl2303?
>> >> >
>> >> > Still using usb-linus with the first LCR write removed.
>> >>
>> >> I can change the baud rate on the ch341 and make it not work with the
>> >> pl2303 (e.g. I send an 'A' from the pl2030 and get an 0xff on the
>> >> ch341, and vice versa), then harmonize the baud rate again and it
>> >> works again.  Changing baud rate seems to work.
>> >
>> > That's good. And just to confirm: you managed to get characters through
>> > at both rates?
>>
>> Yes, indeed.
>>
>> When the baud rates match (tested 9600 and 115200), characters arrive
>> as expected in both directions.
>
> Can you try also the below diagnostics patch on top of usb-next (not
> usb-linus this time)?
>
> It seems we should be able to revert to setting the divisors and lcr
> directly for all CH340 devices, while using the new method for CH341
> only (which requires it).
>
> Just want to make sure that keeping a common init sequence would still
> work first.
>
> Note that I don't expect you to be able to change word size, but
> hopefully a default 8N1 will work while the baud rate would be
> configurable.

If both sides (ch341 and pl2303) are configured 8N1, your new patch
works.  When both sides are configured for the same baud rate, it
works.  Changing ch341 to a different baud rate from the pl2303 is
stops working, which implies that baud rate changes are working.
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: ch341

2016-12-12 Thread Russell Senior 
On Mon, Dec 12, 2016 at 7:54 AM, Johan Hovold  wrote:
> On Mon, Dec 12, 2016 at 07:51:59AM -0800, Russell Senior wrote:
>> On Mon, Dec 12, 2016 at 7:40 AM, Johan Hovold  wrote:
>> > On Mon, Dec 12, 2016 at 07:09:34AM -0800, Russell Senior wrote:
>> >> On Mon, Dec 12, 2016 at 1:54 AM, Johan Hovold  wrote:
>> >>
>> >> > Ok, so maybe your device simply does not support changing the line
>> >> > settings more than once. That is, the initial settings chosen are used
>> >> > until re-connected. This would seem to be in accordance with a comment
>> >> > found in one of the out-of-tree drivers floating around (and which at
>> >> > least I hoped would no longer be an issue with the new way of changing
>> >> > the settings).
>> >> >
>> >> > If you connect the ch340 you have in loopback mode, with the removed
>> >> > initial LCR write that fixed the 5-bit behaviour, can you get that
>> >> > behaviour back by setting 5-bit word size after opening the port? (This
>> >> > was what I was going for with my original question above.).
>> >>
>> >> With minicom configured with 5N1 (that is, 5-bit mode), loopback looks
>> >> normal.  I type an 'a' and I get and 'a' back.  Likewise, I type an
>> >> 'A' and I get an 'A' back.  I used a saved .minicom.dfl file to
>> >> configure the port.
>> >
>> > Ok, so that seems to confirm the suspicion that changing settings after
>> > the initial configuration is failing (even though the device does indeed
>> > support 5-bit mode).
>> >
>> > Could you try to verify if that applies to the baud rate as well? That
>> > is, can you switch between say 9600 and 115200 after opening the port
>> > and verify that against the pl2303?
>> >
>> > Still using usb-linus with the first LCR write removed.
>>
>> I can change the baud rate on the ch341 and make it not work with the
>> pl2303 (e.g. I send an 'A' from the pl2030 and get an 0xff on the
>> ch341, and vice versa), then harmonize the baud rate again and it
>> works again.  Changing baud rate seems to work.
>
> That's good. And just to confirm: you managed to get characters through
> at both rates?

Yes, indeed.

When the baud rates match (tested 9600 and 115200), characters arrive
as expected in both directions.

For what it's worth, changing byte-size to 5-bits on the pl2303 and
sending data from it results in gibberish arriving on the ch341,
implying that the pl2303 is changing byte size.
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: ch341

2016-12-12 Thread Russell Senior 
On Mon, Dec 12, 2016 at 7:40 AM, Johan Hovold  wrote:
> On Mon, Dec 12, 2016 at 07:09:34AM -0800, Russell Senior wrote:
>> On Mon, Dec 12, 2016 at 1:54 AM, Johan Hovold  wrote:
>>
>> > Ok, so maybe your device simply does not support changing the line
>> > settings more than once. That is, the initial settings chosen are used
>> > until re-connected. This would seem to be in accordance with a comment
>> > found in one of the out-of-tree drivers floating around (and which at
>> > least I hoped would no longer be an issue with the new way of changing
>> > the settings).
>> >
>> > If you connect the ch340 you have in loopback mode, with the removed
>> > initial LCR write that fixed the 5-bit behaviour, can you get that
>> > behaviour back by setting 5-bit word size after opening the port? (This
>> > was what I was going for with my original question above.).
>>
>> With minicom configured with 5N1 (that is, 5-bit mode), loopback looks
>> normal.  I type an 'a' and I get and 'a' back.  Likewise, I type an
>> 'A' and I get an 'A' back.  I used a saved .minicom.dfl file to
>> configure the port.
>
> Ok, so that seems to confirm the suspicion that changing settings after
> the initial configuration is failing (even though the device does indeed
> support 5-bit mode).
>
> Could you try to verify if that applies to the baud rate as well? That
> is, can you switch between say 9600 and 115200 after opening the port
> and verify that against the pl2303?
>
> Still using usb-linus with the first LCR write removed.

I can change the baud rate on the ch341 and make it not work with the
pl2303 (e.g. I send an 'A' from the pl2030 and get an 0xff on the
ch341, and vice versa), then harmonize the baud rate again and it
works again.  Changing baud rate seems to work.



>
> Thanks,
> Johan
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: ch341

2016-12-12 Thread Russell Senior 
On Mon, Dec 12, 2016 at 1:54 AM, Johan Hovold  wrote:

> Ok, so maybe your device simply does not support changing the line
> settings more than once. That is, the initial settings chosen are used
> until re-connected. This would seem to be in accordance with a comment
> found in one of the out-of-tree drivers floating around (and which at
> least I hoped would no longer be an issue with the new way of changing
> the settings).
>
> If you connect the ch340 you have in loopback mode, with the removed
> initial LCR write that fixed the 5-bit behaviour, can you get that
> behaviour back by setting 5-bit word size after opening the port? (This
> was what I was going for with my original question above.).

With minicom configured with 5N1 (that is, 5-bit mode), loopback looks
normal.  I type an 'a' and I get and 'a' back.  Likewise, I type an
'A' and I get an 'A' back.  I used a saved .minicom.dfl file to
configure the port.
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: ch341

2016-12-12 Thread Russell Senior 
On Mon, Dec 12, 2016 at 1:54 AM, Johan Hovold  wrote:

> If you connect the ch340 you have in loopback mode, with the removed
> initial LCR write that fixed the 5-bit behaviour, can you get that
> behaviour back by setting 5-bit word size after opening the port? (This
> was what I was going for with my original question above.).

Can you remind me which branch/patch I am testing?  I've lost track
over the weekend.
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: ch341

2016-12-12 Thread Russell Senior 
On Mon, Dec 12, 2016 at 1:48 AM, Johan Hovold  wrote:

> What exactly did you mean by "the baudrate change" above? If you revert
> to setting the divisors directly (rather than using SERIAL_INIT), we
> should be back to how things work in 4.9 (which you can get to work with
> the pl2303 by removing the initial LCR write).

I mean, that I also tried:

  r = ch341_init_set_baudrate(dev, priv, 0);

instead of the

  r = ch341_init_set_baudrate(dev, priv, 0xc3);

in the second part of your patch.
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: ch341

2016-12-09 Thread Russell Senior 
Hi Karl,

The pl2303 has always worked in 8N1 mode for me, talking to serial
devices.  That's all I can say with certainty.

On Fri, Dec 9, 2016 at 8:00 AM, Karl Palsson  wrote:
>
> Can you actually trust that pl2303 module? They're not exactly
> known for being trouble free, and have often been cloned in the
> past as well, with varyings levels of success. Do you have a
> cp210x or ft23x at all?
>
> This is one of the great pitfalls of loopback testing, it doesn't
> test that anything really does what it says, just that it does
> whatever it does consistently.
>
> Sincerely,
> Karl P
>
>
> Russell Senior  wrote:
>> > Also, when the above change makes usb-linus works, does changing the
>> > word size appear to work after probe?
>>
>> I'm not sure what changing the word size is supposed to do. The
>> usb-linus + previous patch in loopback seems to work with
>> minicom regardless of wordsize. More so even than I would guess
>> at 5N1: a -> a, A -> A. Trying to talk with a pl2303, 8N1 on
>> both sides works. 7E1 works sending from ch341 to pl2303, but
>> not pl2303 to ch341 (text is garbled on reception). 6N1 is
>> garbled in both directions, but differently.
>>
>>
>> Russell
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: ch341

2016-12-09 Thread Russell Senior 
> Also, when the above change makes usb-linus works, does changing the
> word size appear to work after probe?

I'm not sure what changing the word size is supposed to do.  The
usb-linus + previous patch in loopback seems to work with minicom
regardless of wordsize.  More so even than I would guess at 5N1: a ->
a, A -> A.  Trying to talk with a pl2303, 8N1 on both sides works.
7E1 works sending from ch341 to pl2303, but not pl2303 to ch341 (text
is garbled on reception). 6N1 is garbled in both directions, but
differently.


Russell
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: ch341

2016-12-09 Thread Russell Senior 
>> Okay, I built your usb-linus
>>
>> 46490c347df406b3368680dd911620e52dc7bfa4
>>
>> with the line:
>>
>>r = ch341_control_out(dev, 0x9a, 0x2518, 0x0050);
>>
>> commented out.  More precisely:
>
>> Loopback works, and also interoperates with pl2303 (through a null
>> modem adapter).
>
> Interesting indeed. The changes in usb-next enabled support for some
> other devices which previously did not work, but hopefully we can find a
> combination that works for all (unless we can reliably determine the
> device-type during probe).
>
> Can you try the below patch on top of my usb-next branch?

With your patch on top of usb-next loopback works (with minicom) but
does not interoperate with pl2303.  I also tried without the baudrate
change, but didn't see a difference.

PS: this testing goes much quicker when I figured out how to rebuild
just the module in question and then rmmod/insmod it. ;-)  I'm
building on an old Core 2 Duo Lenovo ThinkPad W500, a full kernel
build takes about an hour.
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: ch341

2016-12-08 Thread Russell Senior 
On Thu, Dec 8, 2016 at 10:02 AM, Johan Hovold  wrote:
> On Thu, Dec 08, 2016 at 04:41:44AM -0800, Russell Senior wrote:
>> >>>>> "Johan" == Johan Hovold  writes:
>>
>> [...]
>>
>> Johan> Ok, and you were using a terminal program such as minicom that
>> Johan> properly configures the port for say 8-bit words?
>>
>> I was using GNU screen, which I don't specifically configure to be
>> 8-bits, but I retried with minicom and specifically set a different byte
>> size (non-8) and then set it back to 8, and saw the same 5-bit like
>> behavior.
>
> Ok, try sticking to minicom for any further tests just to be sure.
>
>> Johan> [...] But if I configure the port for 5-bit words, I get the
>> Johan> exact sequence you describe (i.e. the three most-significant bits
>> Johan> are masked out).
>>
>> Johan> So my guess is that either you are not configuring the port
>> Johan> correctly (and are using the default settings), or the driver
>> Johan> fails to configure the port (and you are also stuck with the
>> Johan> default settings).
>>
>> Johan> This may be a bit of long shot (or maybe not) but could you try
>> Johan> the below patch on top of usb-next as well? [...]
>>
>> Your patch seems to have fixed it!  Yay!
>
> Interesting. I dug through the archives and found a report from Eddi De
> Pieri which seems to have hit the same issue:
>
> 
> https://lkml.kernel.org/r/CAKdnbx7GTH3K7eGtQ==wh=kb74ea_egpii0h8hxxokljnhh...@mail.gmail.com
>
> The weird part is I appear to have the same device, and it works fine
> without that change.
>
> Could you try and just commenting out that register write in a mainline
> kernel (or my usb-linus branch) to make sure the changes in -next did
> not cause the issues you still see when connected to a pl2303.

Okay, I built your usb-linus

46490c347df406b3368680dd911620e52dc7bfa4

with the line:

   r = ch341_control_out(dev, 0x9a, 0x2518, 0x0050);

commented out.  More precisely:

diff --git a/drivers/usb/serial/ch341.c b/drivers/usb/serial/ch341.c
index f139488..928966a 100644
--- a/drivers/usb/serial/ch341.c
+++ b/drivers/usb/serial/ch341.c
@@ -214,7 +214,7 @@ static int ch341_configure(struct usb_device *dev,
struct ch341_private *priv)
if (r < 0)
goto out;

-   r = ch341_control_out(dev, 0x9a, 0x2518, 0x0050);
+   // r = ch341_control_out(dev, 0x9a, 0x2518, 0x0050);
if (r < 0)
goto out;

Loopback works, and also interoperates with pl2303 (through a null
modem adapter).

>
> Are you using minicom on both ends with 115200 8N1 which appears to
> work reliably, by the way?

Yes, I'm running minicom on both ends.
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: ch341

2016-12-08 Thread Russell Senior 

>>>>> "Johan" == Johan Hovold  writes:

Johan> This may be a bit of long shot (or maybe not) but could you try
Johan> the below patch on top of usb-next as well? [...]

Russell> Your patch seems to have fixed it!  Yay!

Oops, not so fast.  It worked in loopback, but it didn't interoperate
with my pl2303.  Sending anything from the ch341 arrives at the pl2303
as 0x00, sending anything from the pl2303 arrives at the ch341 as 0xff.

Again, this is with GNU screen, started as: "screen /dev/ttyUSB${n}
115200" where ${n} is 0 or 1, depending on the tty.  Though, I seem to
get the same behavior with minicom.


-- 
Russell Senior, President
russ...@personaltelco.net
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: ch341

2016-12-08 Thread Russell Senior 
>>>>> "Johan" == Johan Hovold  writes:

[...]

Johan> Ok, and you were using a terminal program such as minicom that
Johan> properly configures the port for say 8-bit words?

I was using GNU screen, which I don't specifically configure to be
8-bits, but I retried with minicom and specifically set a different byte
size (non-8) and then set it back to 8, and saw the same 5-bit like
behavior.

Johan> [...] But if I configure the port for 5-bit words, I get the
Johan> exact sequence you describe (i.e. the three most-significant bits
Johan> are masked out).

Johan> So my guess is that either you are not configuring the port
Johan> correctly (and are using the default settings), or the driver
Johan> fails to configure the port (and you are also stuck with the
Johan> default settings).

Johan> This may be a bit of long shot (or maybe not) but could you try
Johan> the below patch on top of usb-next as well? [...]

Your patch seems to have fixed it!  Yay!

Johan> What is the lsusb -v output for you device? And what chip version
Johan> is reported when connect the device if you enable dynamic
Johan> debugging on usb-next (e.g. use "modprobe ch341 dyndbg==p").

# lsusb -v -d 1a86:7523

Bus 006 Device 004: ID 1a86:7523 QinHeng Electronics HL-340 USB-Serial adapter
Device Descriptor:
  bLength18
  bDescriptorType 1
  bcdUSB   1.10
  bDeviceClass  255 Vendor Specific Class
  bDeviceSubClass 0 
  bDeviceProtocol 0 
  bMaxPacketSize0 8
  idVendor   0x1a86 QinHeng Electronics
  idProduct  0x7523 HL-340 USB-Serial adapter
  bcdDevice2.54
  iManufacturer   0 
  iProduct2 USB2.0-Ser!
  iSerial 0 
  bNumConfigurations  1
  Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength   39
bNumInterfaces  1
bConfigurationValue 1
iConfiguration  0 
bmAttributes 0x80
  (Bus Powered)
MaxPower   96mA
Interface Descriptor:
  bLength 9
  bDescriptorType 4
  bInterfaceNumber0
  bAlternateSetting   0
  bNumEndpoints   3
  bInterfaceClass   255 Vendor Specific Class
  bInterfaceSubClass  1 
  bInterfaceProtocol  2 
  iInterface  0 
  Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x82  EP 2 IN
bmAttributes2
  Transfer TypeBulk
  Synch Type   None
  Usage Type   Data
wMaxPacketSize 0x0020  1x 32 bytes
bInterval   0
  Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x02  EP 2 OUT
bmAttributes2
  Transfer TypeBulk
  Synch Type   None
  Usage Type   Data
wMaxPacketSize 0x0020  1x 32 bytes
bInterval   0
  Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81  EP 1 IN
bmAttributes3
  Transfer TypeInterrupt
  Synch Type   None
  Usage Type   Data
wMaxPacketSize 0x0008  1x 8 bytes
bInterval   1
Device Status: 0x
  (Bus Powered)


dmesg shows this after reloading the ch341 module after rmmod/modprobe
as above:

[  812.709627] usbcore: registered new interface driver ch341
[  812.709643] usbserial: USB Serial support registered for ch341-uart
[  824.444092] usb 6-2: new full-speed USB device number 4 using uhci_hcd
[  824.622102] usb 6-2: New USB device found, idVendor=1a86, idProduct=7523
[  824.622107] usb 6-2: New USB device strings: Mfr=0, Product=2, SerialNumber=0
[  824.622111] usb 6-2: Product: USB2.0-Ser!
[  824.626324] ch341 6-2:1.0: ch341-uart converter detected
[  824.626421] usb 6-2: ch341_control_in(c0,5f,,,8d7fb5e77e80,8)
[  824.628153] usb 6-2: Chip version: 0x30
[  824.628156] usb 6-2: ch341_control_out(40,a1,,)
[  824.629099] usb 6-2: ch341_control_in(c0,95,2518,,8d7fb5e77e80,8)
[  824.630097] usb 6-2: ch341_control_out(40,9a,2518,00c3)
[  824.631096] usb 6-2: ch341_control_in(c0,95,0706,,8d7fb5e77e78,8)
[  824.632164] usb 6-2: ch341_control_out(40,a1,009c,b282)
[  824.633098] usb 6-2: ch341_control_out(40,a4,ff9f,)
[  824.634097] usb 6-2: ch341_control_in(c0,95,0706,,8d7fb5e77e78,8)
[  824.635309] usb 6-2: ch341-uart converter now attached to ttyUSB0


-- 
Russell Senior, President
russ...@personaltelco.net
--
To unsubscribe from this list: send the line "unsubscribe linux-

Re: ch341

2016-12-07 Thread Russell Senior 
>>>>> "Johan" == Johan Hovold  writes:

>> I attach the tty's with GNU screen (but I have also tried microcom
>> and minicom with the same results).  This was my first experience
>> with or even awareness of ch341. I have much more experience with
>> pl2303 and somewhat less with ftdi.  With these ch341, when I type in
>> an 'a' on one terminal, I get 0x01 out the other terminal.  If I type
>> in a 'b', I get an 0x02, etc, on up to 'z' yielding 0x1a.
>> 
>> I found your name/contact in the git commits.
>> 
>> Any idea what is going on?

Johan> Sounds like it could be related to an incorrect line setting
Johan> (e.g. the devices are using 5-bit words). Some changes just went
Johan> in that add support for changing this. Could you try building a
Johan> kernel based on the usb-next branch of:

Johan>  git://git.kernel.org/pub/scm/linux/kernel/git/johan/usb-serial.git

Johan> and see if that works better?

I built usb-next (3c3dd1e) and saw the same behavior.  Loopback
(connecting RX and TX) worked on pl2303-based usb-serial adapter (with
PC levels, not TTL), and did not ('a' -> 0x01, 'b' -> 0x02, etc) with
ch341-based usb-serial adapter (again with PC levels, measured MIN/MAX
voltages with a DVM and saw, about -7V/+7V).

I still suspect shoddy hardware.  It would be nice to hear someone else
with the ch341-based hardware to say it works for them.


-- 
Russell Senior, President
russ...@personaltelco.net
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: ch341

2016-12-07 Thread Russell Senior 

Hi,

I just bought a bag of usb-serial converters off of ebay, from china for
super low price (~$2/each).  I just plugged a couple of them in,
connected together through a null-modem adapter.  When I plug them, on
both stock ubuntu 16.04's kernel and 4.8.9 built from git, I get a
reasonable looking dmesg:

[822616.501963] usb 2-2.3: new full-speed USB device number 16 using xhci_hcd
[822616.602985] usb 2-2.3: New USB device found, idVendor=1a86, idProduct=7523
[822616.602988] usb 2-2.3: New USB device strings: Mfr=0, Product=2, 
SerialNumber=0
[822616.602989] usb 2-2.3: Product: USB2.0-Ser!
[822617.633618] usbcore: registered new interface driver usbserial
[822617.633638] usbcore: registered new interface driver usbserial_generic
[822617.633653] usbserial: USB Serial support registered for generic
[822617.638736] usbcore: registered new interface driver ch341
[822617.638755] usbserial: USB Serial support registered for ch341-uart
[822617.638770] ch341 2-2.3:1.0: ch341-uart converter detected
[822617.640272] usb 2-2.3: ch341-uart converter now attached to ttyUSB0
[822625.294363] usb 2-2.2: new full-speed USB device number 17 using xhci_hcd
[822625.395324] usb 2-2.2: New USB device found, idVendor=1a86, idProduct=7523
[822625.395327] usb 2-2.2: New USB device strings: Mfr=0, Product=2, 
SerialNumber=0
[822625.395328] usb 2-2.2: Product: USB2.0-Ser!
[822625.396487] ch341 2-2.2:1.0: ch341-uart converter detected
[822625.397575] usb 2-2.2: ch341-uart converter now attached to ttyUSB1

I attach the tty's with GNU screen (but I have also tried microcom and
minicom with the same results).  This was my first experience with or
even awareness of ch341. I have much more experience with pl2303 and
somewhat less with ftdi.  With these ch341, when I type in an 'a' on one
terminal, I get 0x01 out the other terminal.  If I type in a 'b', I get
an 0x02, etc, on up to 'z' yielding 0x1a.

I found your name/contact in the git commits.

Any idea what is going on?

My leading theory at the moment is that the manufacturer didn't populate
all the parts, and the vendor got an great deal on them, which they
passed on to me!


-- 
Russell Senior, President
russ...@personaltelco.net
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: cannot submit datapipe for urb 0, error -28: not enough bandwidth

2007-12-19 Thread Russell Senior 
>>>>> "Alan" == Alan Stern <[EMAIL PROTECTED]> writes:

Alan> On 19 Dec 2007, Russell Senior wrote:
>> I have an application on an embedded device.  It was all happily
>> working with a usb-storage device, a pl2303-based gps device and a
>> usb-audio device plugged into a usb2 hub.  Now I've added a usb
>> mouse and when I open the associated /dev/event0, I start seeing
>> the messages below when I try to play audio to the usb-audio
>> device.
>> 
>> cannot submit datapipe for urb 0, error -28: not enough bandwidth
>> output: ioctl(SNDCTL_DSP_SYNC): Broken pipe cannot submit datapipe
>> for urb 0, error -28: not enough bandwidth cannot submit datapipe
>> for urb 0, error -28: not enough bandwidth output:
>> ioctl(SNDCTL_DSP_SYNC): Broken pipe cannot submit datapipe for urb
>> 0, error -28: not enough bandwidth
>>
>> [...]
>> 
>> With gpsd running (opening /dev/ttyUSB0), with "cat < /dev/event0 >
>> /dev/null", then "/usr/bin/madplay -Q -a -10 --no-tty-control
>> random.mp3" seems to screw me.  Without the /dev/event0 open, I
>> don't have the problem.
>> 
>> Am I screwed, or is there something I can tweak?

Alan> You can try replacing your hub.  Some USB 2.0 hubs have greater
Alan> bandwidth capacity for full-speed devices than yours (they have
Alan> separate Transaction Translators for each port).

Can you suggest one?  I have a few lying around to try, but if I have
to buy one I'd like to get the right one the first time.

Alan> Or you can try plugging some of those full-speed devices
Alan> directly into the computer rather than into the hub.  

Regrettably, the board has but one usb port.

Alan> The storage device doesn't matter, but the gps, audio, and mouse
Alan> devices are all sharing the hub's bandwidth.

Right.  Thanks!


-- 
Russell Senior ``I have nine fingers; you have ten.''
[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

cannot submit datapipe for urb 0, error -28: not enough bandwidth

2007-12-19 Thread Russell Senior 
If#= 0 Alt= 0 #EPs= 1 Cls=09(hub  ) Sub=00 Prot=00 Driver=hub
  E:  Ad=81(I) Atr=03(Int.) MxPS=   2 Ivl=255ms

  T:  Bus=01 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#=  1 Spd=12  MxCh= 1
  B:  Alloc=  0/900 us ( 0%), #Int=  0, #Iso=  0
  D:  Ver= 1.10 Cls=09(hub  ) Sub=00 Prot=00 MxPS=64 #Cfgs=  1
  P:  Vendor= ProdID= Rev= 2.06
  S:  Manufacturer=Linux 2.6.23.1 ohci_hcd
  S:  Product=OHCI Host Controller
  S:  SerialNumber=:00:02.0
  C:* #Ifs= 1 Cfg#= 1 Atr=e0 MxPwr=  0mA
  I:* If#= 0 Alt= 0 #EPs= 1 Cls=09(hub  ) Sub=00 Prot=00 Driver=hub
  E:  Ad=81(I) Atr=03(Int.) MxPS=   2 Ivl=255ms

These modules are loaded:

  $ lsmod
  Module  Size  Used byNot tainted
  usbhid 26160  0 
  hid73552  1 usbhid
  evdev   6016  2 
  input_core 18992  6 usbhid,hid,evdev
  pl2303 15312  1 
  usb_storage27680  1 
  usbserial  24448  3 pl2303
  snd_usb_audio  57088  0 
  snd_usb_lib11904  1 snd_usb_audio
  ehci_hcd   28560  0 
  ohci_hcd   15088  0 
  sd_mod 18512  2 
  nf_nat_tftp  480  0 
  nf_conntrack_tftp   2480  1 nf_nat_tftp
  nf_nat_irc   960  0 
  nf_conntrack_irc2832  1 nf_nat_irc
  nf_nat_ftp  1472  0 
  nf_conntrack_ftp5152  1 nf_nat_ftp
  snd_pcm_oss40032  0 
  snd_mixer_oss  13728  1 snd_pcm_oss
  snd_pcm57056  2 snd_usb_audio,snd_pcm_oss
  snd_timer  16144  1 snd_pcm
  snd_rawmidi15936  1 snd_usb_lib
  snd_hwdep   4784  1 snd_usb_audio
  snd_page_alloc  5168  1 snd_pcm
  snd35280  7 
snd_usb_audio,snd_pcm_oss,snd_mixer_oss,snd_pcm,snd_timer,snd_rawmidi,snd_hwdep
  soundcore   3664  1 snd
  vfat8576  1 
  fat42480  1 vfat
  nls_iso8859_1   2880  1 
  nls_cp437   4416  1 
  usbcore   106224  9 
usbhid,pl2303,usb_storage,usbserial,snd_usb_audio,snd_usb_lib,ehci_hcd,ohci_hcd
  scsi_mod   71584  2 usb_storage,sd_mod
  nls_base4416  4 vfat,fat,nls_iso8859_1,nls_cp437
  switch_robo 4048  0 
  switch_core         5056  1 switch_robo
  diag8272  0 



-- 
Russell Senior ``I have nine fingers; you have ten.''
[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html