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> Ok, and you were using a terminal program such as minicom that >>> Johan> properly configures the port for say 8-bit words? >>> >>> I was using GNU screen, which I don't specifically configure to be >>> 8-bits, but I retried with minicom and specifically set a different byte >>> size (non-8) and then set it back to 8, and saw the same 5-bit like >>> behavior. >> >> Ok, try sticking to minicom for any further tests just to be sure. >> >>> 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: > > diff --git a/drivers/usb/serial/ch341.c b/drivers/usb/serial/ch341.c > index f139488..928966a 100644 > --- a/drivers/usb/serial/ch341.c > +++ b/drivers/usb/serial/ch341.c > @@ -214,7 +214,7 @@ static int ch341_configure(struct usb_device *dev, > struct ch341_private *priv) > if (r < 0) > goto out; > > - r = ch341_control_out(dev, 0x9a, 0x2518, 0x0050); > + // r = ch341_control_out(dev, 0x9a, 0x2518, 0x0050); > if (r < 0) > goto out; > > 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. 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). -- 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
