Hi Karl, I don't know but as documented by usbsnoop log the value written from kernel driver make my device to fail.
Windows driver after some assumption write back the original value (0xc3) Regards, Eddi On Sun, Feb 8, 2015 at 2:54 AM, Karl Palsson <ka...@tweak.net.au> wrote: > > My work in > > > Eddi De Pieri <e...@depieri.net> wrote: >> Bus 003 Device 014: ID 1a86:7523 QinHeng Electronics HL-340 USB-Serial >> adapter >> >> ch431 kernel driver don't work correctly with this device, >> when URB_FUNCTION_BULK_OR_INTERRUPT_TRANSFER answer/send wrong character >> >> After some experiment by passing command retrieved from usbsnoop log >> it seems that ch341.c starts working if comment out following line >> >> // r = ch341_control_out(dev, 0x9a, 0x2518, 0x0050); >> >> my windows driver usbsnoop | grep "18 25" >> 000007: 000003 ms 000398 ms c0 95 18 25 00 00 02 00 <<< c3 00 >> 000036: 000004 ms 000620 ms 40 9a 18 25 c2 00 00 00 >>> >> 000075: 000003 ms 011673 ms 40 9a 18 25 c3 00 00 00 >>> >> >> as you can see I get c3 while who first logged windows driver sniff get >> 56. > > My work in progress updates to this driver had already marked that line > as suspicious. > My draft comment is "this sets break + 5 bit mode, why?!" On a ch340, > this _should_ have just been ignored, as it doesn't support 5 bit mode. > Also, "break" on this device is actually by disabling the rx and tx > sides, there's a bit in that register for both directions to be enabled > individually. > > It's a little sad that your hl340 device fails, as those are the only > ones that have been working for me so far. ch341 devices don't work > reliably at all. > >> please note that my device after following command >> r = ch341_control_in(dev, 0x5f, 0, 0, buffer, size); ( >> answer 0x3000, so it should be a more recent hardware version. >> >> ch34x linux driver from the oem confirmed that 0x5f means hardware >> version) >> >> I need someone that have same device or other devices that needs >> ch341.ko to check that it works properly even if you comment out >> before sending a patch back to the ML. >> > > It needs a lot more than just commenting out that line unfortunately. > Good news, I'm working on this again, bad news, I said that 6 months ago > too :( > > My current work is at https://github.com/karlp/linux/tree/ch341-3.18.6 > but note that this is only the initial cleanup, no fixes at this stage. > > Sincerely, > Karl Palsson -- 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
