On Fri, Dec 09, 2016 at 10:21:32AM +0000, Aidan Thornton wrote: > On Fri, Dec 9, 2016 at 3:26 AM, Russell Senior > <russell@xxxxxxxxxxxxxxxxx> wrote: > > On Thu, Dec 8, 2016 at 10:02 AM, Johan Hovold <johan@xxxxxxxxxx> wrote: > >> On Thu, Dec 08, 2016 at 04:41:44AM -0800, Russell Senior wrote: > >>> >>>>> "Johan" == Johan Hovold <johan@xxxxxxxxxx> writes: > >>> 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_eGpii0h8HXxOkLjnhhfPw@xxxxxxxxxxxxxx > >> > >> 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: > > Loopback works, and also interoperates with pl2303 (through a null > > modem adapter). > > Interesting. Don't suppose you could check if usb-next works with this > commented out, please? Hopefully it should because that more or less > matches up with what the manufacturer was doing, and they ought to > know what they're doing. Unless we're dealing with some counterfeit device here... > Johan, feel free to rip this register write out - I tested both with > and without it when submitting those patches and couldn't find any > noticeable difference on the hardware I was using, would have removed > it back then if I'd looked back far enough in the archives to spot > that email. Sorry about that. Only left it there in case removing it > broke some odd hardware revision, but it sounds like leaving it in > breaks some hardware badly (judging from the reported symptoms, baud > rate setting and changing the line control register probably don't > work via either method afterwards). No worries, this game is frustrating, but we need to try to find an initialisation sequence that works for all or most device types while trying to be conservative in the changes we make not cause any regressions. I now have a CH340G and CH341A and can do some basic testing, while Russel seem to have some variant of CH340 that behaves differently. With this test coverage I think we should be able to find some sequence that works. Thanks, Johan -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
