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?).
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
--
To unsubscribe from this list: send the line "unsubscribe stable" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html