linux-usb.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Nicolas Frattaroli <frattaroli.nicolas@gmail.com>
To: gregkh@linuxfoundation.org, johan@kernel.org,
	Corentin Labbe <clabbe@baylibre.com>
Cc: linux-kernel@vger.kernel.org, linux-usb@vger.kernel.org,
	david@ixit.cz, Corentin Labbe <clabbe@baylibre.com>
Subject: Re: [PATCH v6 0/2] usb: serial: add support for CH348
Date: Wed, 30 Aug 2023 19:43:03 +0200	[thread overview]
Message-ID: <2595072.9XhBIDAVAK@archbook> (raw)
In-Reply-To: <20230628133834.1527941-1-clabbe@baylibre.com>

On Mittwoch, 28. Juni 2023 15:38:32 CEST Corentin Labbe wrote:
> Hello
> 
> The CH348 is an octo serial to USB adapter.
> The following patch adds a driver for supporting it.
> Since there is no public datasheet, unfortunatly it remains some magic values.
> 
> It was tested with a large range of baud from 1200 to 1500000 and used with
> success in one of our kernel CI testlab.
> 
> Regards
> 
> [...]

Hello,

thank you for your work on this. I recently made myself a CH348
board and used this patchset with a small test application[1]
to see how it performs. Specifically, I ran this on an RK3566
single board computer, connecting one serial adapter to the
other, with the test as follows:

 ./serialtest /dev/ttyUSB0 9600 # UART0 of 1st CH348 board
 ./serialtest /dev/ttyUSB8 9600 # UART0 of 2nd CH348 board

One problem I've noticed is that writes to the tty fd never
seem to block. On two CH340 adapters I have, they do seem to
block, whereas here, you can see from the statistics at the
end that magnitudes more bytes were written than read, with
seemingly most of them being discarded. From my reading of
the termios parameters I set, this shouldn't be the case,
right?

You can see from the error percentage that it gets less
bad as you increase the serial baudrate; I've tested up
to 6 mbaud like this. I assume that's because less written
bytes get discarded.

Any ideas on whether I'm relying on weird driver behaviour
with the blocking here or if this driver actually has a
defect whereby it never signals to userspace that less
bytes were written than have been submitted?

Kind regards,
Nicolas Frattaroli

[1]: https://github.com/CounterPillow/serialtest



  parent reply	other threads:[~2023-08-30 18:31 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-06-28 13:38 [PATCH v6 0/2] usb: serial: add support for CH348 Corentin Labbe
2023-06-28 13:38 ` [PATCH v6 1/2] " Corentin Labbe
2023-06-28 13:38 ` [PATCH v6 2/2] usb: serial: add myself as maintainer of CH348 Corentin Labbe
2023-07-01 19:16 ` [PATCH v6 0/2] usb: serial: add support for CH348 David Heidelberg
2023-08-16 23:34 ` David Heidelberg
2023-08-30 17:43 ` Nicolas Frattaroli [this message]
2023-09-27 12:09   ` David Heidelberg
2023-11-20 12:29   ` Corentin LABBE
2024-04-03 13:27     ` David Heidelberg
2024-04-10 20:04       ` Corentin LABBE

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=2595072.9XhBIDAVAK@archbook \
    --to=frattaroli.nicolas@gmail.com \
    --cc=clabbe@baylibre.com \
    --cc=david@ixit.cz \
    --cc=gregkh@linuxfoundation.org \
    --cc=johan@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-usb@vger.kernel.org \
    /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
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).