On Tue, Jul 12, 2022 at 06:53:38PM +0200, Johan Hovold wrote: > On Tue, Jul 12, 2022 at 02:43:41PM +0200, Greg Kroah-Hartman wrote: > > On Tue, Jul 12, 2022 at 09:29:57PM +0930, Jonathan Woithe wrote: > > > I have done a git bisect which identified the following commit as the source > > > of the problem. > > > > > > commit 55fa15b5987db22b4f35d3f0798928c126be5f1c > > > Author: Johan Hovold <johan@xxxxxxxxxx> > > > Date: Fri Jan 6 19:15:16 2017 +0100 > > > > Please always cc: the developer who wrote a commit that you have > > questions about, so that they are sure to see it, otherwise it's just > > random luck :) > > Thanks for the report, and for forwarding it. Apologies for overlooking the CC in this instance. > > > It would be great if this regression could be addressed. At present I must > > > boot a pre-4.10 kernel whenever I need to use the programming dongle with > > > this converter. > > > > > > Please let me know if there is anything I can do to help resolve the > > > problem. > > > > If you revert this commit on top of the latest kernel release, does it > > solve the problem for you? > > Simply reverting the commit blamed by the bisection should only makes > things worse, at least for some device types. > > Perhaps we need to set that bit 7 based on the type, even if the bit > meaning having been inverted seems a bit far-fetched. > > Jonathan, could you try simply commenting out the > > val |= BIT(7); > > statement in ch341_set_baudrate_lcr()? Commenting out the above line brought some improvement. In minicom with a loopback connector in place, the first byte sent does not get echoed back at all. However, all other bytes are echoed as soon as they are sent. The kernel used for the above test was 672c0c5 (5.18-rc5), which is the most recent I can conveniently get onto the test machine at present. I tested the unmodified kernel before commenting out the line and confirmed that it exhibited the full fault condition (bytes come back in blocks of 32). > Also, what chip version do you have (see debug statement in > ch341_configure())? Chip revision is 0x27. Regards jonathan
