From: Johan Hovold <email@example.com> To: Willy Tarreau <firstname.lastname@example.org> Cc: Greg Kroah-Hartman <email@example.com>, firstname.lastname@example.org, email@example.com, firstname.lastname@example.org Subject: Re: [PATCH] USB: serial: ch341: fix character loss at high transfer rates Date: Thu, 29 Jul 2021 13:51:58 +0200 [thread overview] Message-ID: <YQKWXlTj02OW/h5S@hovoldconsulting.com> (raw) In-Reply-To: <email@example.com> On Sat, Jul 24, 2021 at 05:27:39PM +0200, Willy Tarreau wrote: > The chip supports high transfer rates, but with the small default buffers > (64 bytes read), some entire blocks are regularly lost. This typically > happens at 1.5 Mbps (which is the default speed on Rockchip devices) when > used as a console to access U-Boot where the output of the "help" command > misses many lines and where "printenv" mangles the environment. > > The FTDI driver doesn't suffer at all from this. One difference is that > it uses 512 bytes rx buffers and 256 bytes tx buffers. Adopting these > values completely resolved the issue, even the output of "dmesg" is > reliable. I preferred to leave the Tx value unchanged as it is not > involved in this issue, while a change could increase the risk of > triggering the same issue with other devices having too small buffers. Since these device do not support automatic flow control this is indeed the best we can to do here (otherwise I'd probably prefer framing it more as an optimisation than a fix). > I verified that it backports well (and works) at least to 5.4. It's of > low importance enough to be dropped where it doesn't trivially apply > anymore. This should be fine to backport to all stable trees. > Cc: firstname.lastname@example.org > Signed-off-by: Willy Tarreau <email@example.com> Now applied for 5.14, thanks. Johan
prev parent reply other threads:[~2021-07-29 11:52 UTC|newest] Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-07-24 15:27 Willy Tarreau 2021-07-29 11:51 ` Johan Hovold [this message]
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=YQKWXlTj02OW/h5S@hovoldconsulting.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --subject='Re: [PATCH] USB: serial: ch341: fix character loss at high transfer rates' \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).