Hello Corentin,
is there chance you find some time to upstream this?
In the worst case I would try to find some time to look into this, so it
would have chance to get merged.
Thanks
David
On 20/11/2023 13:29, Corentin LABBE wrote:
Le Wed, Aug 30, 2023 at 07:43:03PM +0200, Nicolas Frattaroli a écrit :
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
Hello
Sorry for the very long delay of the answer.
I have reproduced the problem on my board.
My reproducer is https://github.com/montjoie/lava-tests/blob/master/test2a2.py
This problem seems to be here since the v1 of my patchset.
The vendor driver seems to work so it is not an hardware problem.
I have no clue at the moment, it is hard to diff with vendor driver since it create tty directly and do not use usbserial.
Regards
--
David Heidelberg
