Re: [Regression] CH341 USB-serial converter passes data in 32 byte chunks

Jonathan Woithe
2022-07-18T02:49:30Z

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