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

Changes since v1:
- use a data structure for encoding/decoding messages.
- check if needed endpoints exists
- fix URB leak in ch348_allocate_status_read error case
- test for maximum baud rate as stated by datasheet

Changes since v2:
- specify ch348_rxbuf data length
- Use correct speed_t dwDTERate instead of __le32
- test for maximum baud rate supported according to datasheet
- Use a define for CH348_TX_HDRSIZE

Changes since v3
- Fixed all reported problem from https://lore.kernel.org/lkml/Y5NDwEakGJbmB6+b@Red/T/#mb6234d0427cfdabf412190565e215995a41482dd
  Mostly reworked the endpoint mux to be the same than mx_uport

Changes since v4:
- The V4 was sent against stable and next have ch348_set_termios ktermios
  parameter const that I forgot to change

Changes since v5:
- Fixed all reported problem from
+https://lore.kernel.org/lkml/20230106135338.643951-1-clabbe@baylibre.com/T/#m044aab24dfb652ea34aa06f8ef704da9d6a2e036
- Major change is dropping of all status handling which was unused.
  It will be probably necessary to bring it back when using GPIO.
  This will be done when I will finish my next devboard.

Changes since v6:
- read and print the device version during probe
- Only request one bulk out channel from usb-serial core
- Implement status report / interrupt handling
- Fix buffer->rate calculation / enable support for slow baud rates
- use a mutex to protect against concurrent writes
- split write buffers for slow baud rates

Important note, v7 is mostly done from work of Martin Blumenstingl,
so the changelog was built from https://github.com/xdarklight/ch348/commits/main/

changes since v7:
- Use standard configuration and interrupt status macros from
  <linux/serial_reg.h> as suggested by Johan Hovold (thank you)
- Update logging (avoiding %s to print the function name and
  rate-limiting logs from ch348_process_status_urb() which may be
  called a lot) as suggested by Johan Hovold
- Use usb-serial integration for parsing all endpoint descriptors for
  us. As result of this usb-serial and ch348_process_read_urb() are
  now managing the status/interrupt endpoint as well
- Move processing of the write buffer(s) to a workqueue. ch348 does
  not allow multiple parallel write URBs (with serial TX data).
  usb-serial core however tries to always make sure that the buffers
  are full and sending them back-to-back. This does not work for ch348
  as it leads to data corruption.
- Don't use bitfields in struct ch348_status_entry as it's part of an
  ABI. Thanks to Johan Hovold for pointing this out.
- Use #defines for magic values and spell out cases as Suggested by
  Johan Hovold
- Drop support for baud rates outside the range from the datasheet.
  Slower and faster baud rates were added with v7. Testing for this was
  done by connecting two ch348 ports together. However, when using
  another device these faster and slower baud rates are not applied as
  discovered and analyzed (with a scope) by Volker Richter (thank you!)
- Keep the package type around in struct ch348 as it's needed when
  modem controls and/or GPIOs are implemented.

Again, v8 is a work from Martin, I probably will never finish this work
without him.
Great thanks to him again

Corentin Labbe (2):
  usb: serial: add support for CH348
  usb: serial: add Martin and myself as maintainers of CH348

 MAINTAINERS                 |   6 +
 drivers/usb/serial/Kconfig  |   9 +
 drivers/usb/serial/Makefile |   1 +
 drivers/usb/serial/ch348.c  | 736 ++++++++++++++++++++++++++++++++++++
 4 files changed, 752 insertions(+)
 create mode 100644 drivers/usb/serial/ch348.c

-- 
2.45.2

On Tue, 4 Feb 2025 13:58:40 +0000 Corentin Labbe wrote:
> The CH348 is an USB octo port serial adapter.
> The device multiplexes all 8 ports in the same pair of Bulk endpoints.
> Since there is no public datasheet, unfortunately it remains some magic
> values
>
> Signed-off-by: Corentin Labbe <clabbe@baylibre.com>
> ---
>  drivers/usb/serial/Kconfig  |   9 +
>  drivers/usb/serial/Makefile |   1 +
>  drivers/usb/serial/ch348.c  | 736 ++++++++++++++++++++++++++++++++++++
>  3 files changed, 746 insertions(+)
>  create mode 100644 drivers/usb/serial/ch348.c
>

Tested-by: Nicolas Frattaroli <frattaroli.nicolas@gmail.com>

Quickly gave this another test by just connecting two ports of a CH348 device
together and making sure data arrives unchowdered at the other end when sending
at full speed with various baud rates. Seems to work about as well as I
expected my jumper wires to hold up at higher baudrates.

I'll likely use this to lessen the pile of active USB-to-serial devices on my
desk while working, so many thanks for keeping up the good work on the driver.
That way it'll also get some more in-depth real world testing in th e coming
weeks, but I doubt it needs more testing at this stage.

Regards,
Nicolas Frattaroli

If another Tested-by is needed to get this in, I can build kernel w/ 
driver and give it shot too.

Thanks for your work & testing!

On 30/03/2025 03:24, Nicolas Frattaroli wrote:
> On Tue, 4 Feb 2025 13:58:40 +0000 Corentin Labbe wrote:
>> The CH348 is an USB octo port serial adapter.
>> The device multiplexes all 8 ports in the same pair of Bulk endpoints.
>> Since there is no public datasheet, unfortunately it remains some magic
>> values
>>
>> Signed-off-by: Corentin Labbe <clabbe@baylibre.com>
>> ---
>>   drivers/usb/serial/Kconfig  |   9 +
>>   drivers/usb/serial/Makefile |   1 +
>>   drivers/usb/serial/ch348.c  | 736 ++++++++++++++++++++++++++++++++++++
>>   3 files changed, 746 insertions(+)
>>   create mode 100644 drivers/usb/serial/ch348.c
>>
> 
> Tested-by: Nicolas Frattaroli <frattaroli.nicolas@gmail.com>
> 
> Quickly gave this another test by just connecting two ports of a CH348 device
> together and making sure data arrives unchowdered at the other end when sending
> at full speed with various baud rates. Seems to work about as well as I
> expected my jumper wires to hold up at higher baudrates.
> 
> I'll likely use this to lessen the pile of active USB-to-serial devices on my
> desk while working, so many thanks for keeping up the good work on the driver.
> That way it'll also get some more in-depth real world testing in th e coming
> weeks, but I doubt it needs more testing at this stage.
> 
> Regards,
> Nicolas Frattaroli

-- 
David Heidelberg