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