On Tue, Jul 12, 2022 at 09:29:57PM +0930, Jonathan Woithe wrote:
> Hi all
>
> For many years I have been using a CH341 USB-serial converter (VID:PID
> 4348:5523) to drive a microcontroller programming dongle. This was under
> kernel 4.4.14. When I recently upgraded the machine to a 5.15.27 kernel the
> programmer stopped working, reporting timeouts. Using a loopback cable and
> minicom I discovered that under 5.15.27 data was only delivered back to
> minicom in blocks of 32 characters. This explains why the programming
> software reported timeouts. It seems that either outgoing data is blocked
> until 32 bytes are ready for transmission, or receive data is only reported
> in blocks of 32 bytes.
>
> Under 4.4.14 (and all kernels prior to 4.10.0), individual characters are
> echoed back by minicom as soon as they hare pressed on the keyboard.
>
> As far as I can tell, the regression affects all kernels since 4.10.0.
>
> 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 :)
> USB: serial: ch341: fix baud rate and line-control handling
>
> Revert to using direct register writes to set the divisor and
> line-control registers.
>
> A recent change switched to using the init vendor command to update
> these registers, something which also enabled support for CH341A
> devices. It turns out that simply setting bit 7 in the divisor register
> is sufficient to support CH341A and specifically prevent data from being
> buffered until a full endpoint-size packet (32 bytes) has been received.
>
> Using the init command also had the side-effect of temporarily
> deasserting the DTR/RTS signals on every termios change (including
> initialisation on open) something which for example could cause problems
> in setups where DTR is used to trigger a reset.
>
> Fixes: 4e46c410e050 ("USB: serial: ch341: reinitialize chip on
> reconfiguration")
> Signed-off-by: Johan Hovold <johan@xxxxxxxxxx>
It seems like this change does the opposite of what it says, we don't
want the device to wait for a full endpoint of packets to send stuff
out, right?
> 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?
thanks,
greg k-h
