On Wed, Jul 13, 2022 at 09:52:20AM +0930, Jonathan Woithe wrote: > 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: > > > > 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. Is there anything further I can do or provide to help identify a solution to the regression? Regards jonathan
