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

[Johan Hovold <johan@kernel.org>]

On Tue, Dec 20, 2016 at 05:07:48PM +0100, Johan Hovold wrote:
> On Tue, Dec 20, 2016 at 04:38:19AM -0800, Russell Senior wrote:
> > > 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: [17] = 00
> > Dec 20 04:31:14 willard kernel: ch341 6-2:1.0: [18] = c3
> 
> Ok, so the device only returns the value of the LCR when read together
> with 0x25. Otherwise all zero.
> 
> > Dec 20 04:31:14 willard kernel: ch341 6-2:1.0: write 0x31 0xb282
> 
> > Dec 20 04:31:14 willard kernel: ch341 6-2:1.0: [18] = f1
> 
> And as before it it looks to be updated correctly through a direct
> write, even though tx_en and rx_en is always set.
> 
> My guess is this is some CH341 clone that mimics the behaviour of some
> version of the chip, especially as the vendor does not seem to bother to
> support it (unless it's a new version?).

Then again, if the vendor driver for another OS works, they at least do
care about those users. Perhaps someone can trace what a recent driver
does when encountering these devices.

> I think sticking to using the init command for all devices, except when
> detecting a device that fails to read the divisor registers and then
> fall back to direct writes might be the way forward. That way, we'd
> have some minimal support for these devices at least.
> 
> 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)?
> 
> Any other suggestions?
 
Thanks,
Johan