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

[Jonathan Woithe <jwoithe@just42.net>]

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