Message-ID: <CAFBinCD19CVc0kX-aqa8pw71O2F3Nwy9ght+2TCn9B4PbOCBfw@mail.gmail.com>
Date: Sat, 29 Nov 2025 16:59:36 +0100
From: Martin Blumenstingl <martin.blumenstingl@...glemail.com>
To: Johan Hovold <johan@...nel.org>
Cc: Corentin Labbe <clabbe@...libre.com>, gregkh@...uxfoundation.org, 
	linux-kernel@...r.kernel.org, linux-usb@...r.kernel.org, david@...t.cz
Subject: Re: [PATCH v8 1/2] usb: serial: add support for CH348

Hi Johan,

On Wed, Aug 27, 2025 at 12:08 PM Johan Hovold <johan@...nel.org> wrote:
>
> On Mon, Aug 04, 2025 at 11:35:35PM +0200, Martin Blumenstingl wrote:
> > On Mon, Aug 4, 2025 at 2:32 PM Johan Hovold <johan@...nel.org> wrote:
> > > On Tue, Jul 29, 2025 at 10:45:20PM +0200, Martin Blumenstingl wrote:
>
> > > > My general flow is:
> > > > - check if we have received THRE - if not: don't transmit more data on this port
> > > > - submit up to two URBs with up to 512 - 3 (CH348_TX_HDRSIZE) bytes to
> > > > not exceed the HW TX FIFO size of 1024 bytes (page 1 in the datasheet)
> > > > if the kfifo has enough data
> > >
> > > If you're going to wait for the device fifo to clear completely you can
> > > just use a single urb with larger (1k) buffer too.
>
> > I set .bulk_out_size = 1024 in struct usb_serial_driver. Writing a 1k
> > buffer immediately results in:
> >    ch348 1-1:1.0: device disconnected
> >
> > I don't know if I need to set some kind of flag on the URB to have it
> > split or whether the kernel / USB controller does that automatically
> > (as you can tell: I'm not familiar with USB).
> > If not: 512 byte transfers at a time it is.
>
> The host controller should split the buffer, but apparently this crashes
> the device firmware.
I think having a 512 - 3 (TX header) byte limitation for the TX buffer
is acceptable for the first upstream version of this driver.

> > > > > > On my test board the CFG pin is HIGH. From how I understand you, RTS
> > > > > > should at least change (even if DTR is in TNOW mode).
> > > > > > No matter what I do: both pins are always LOW (right after modprobe,
> > > > > > after opening the console, closing the console again, ...).
> > > > > > I even set up the vendor driver to test this: it's the same situation there.
> > > > >
> > > > > I don't think the console code will assert DTR/RTS, you need to open the
> > > > > port as a regular tty.
> > >
> > > Yes, even if the device is configured in hardware for TNOW mode (instead
> > > of DTR function) you should still be able to control RTS (at least as
> > > long as the device is not configured for automatic hardware flow control).
>
> > I think I made it work, sort of.
> > It's a bit annoying because of code I don't understand. It seems that
> > R_4 has the following settings:
> > 0x00 DTR off
> > 0x01 DTR on
> > 0x10 RTS off
> > 0x11 RTS on
> > 0x08 activate (used during port initialization)
> > 0x50 HW flow on
> > 0x51 no RTS / HW flow off
> >
> > That said, poking 0x00, 0x01, 0x10 and 0x11 by themselves didn't do much.
> > One also has to write 0x06 to the per-port VEN_R register.
> > The vendor driver only does that in .set_termios, which I call
> > questionable until someone calls me out on this and is willing to
> > share a good reason why that's a good idea ;-)
> >
> > However, I'm unable to control the RTS line of port 1. It works for
> > port 0, port 2 and 3 but not for port 1.
> > Ports 4-7 don't have the TNOW/DTR and RTS lines routed outside the
> > package, so I can't test these.
>
> Sounds like good progress. Have you made sure HW flow isn't just enabled
> by default on port 1 or similar?
Unfortunately I don't know how to read the HW flow control state from
the hardware.
Do you have any suggestions, how I can test HW flow control (after
manually enabling it for a port)?
I have a logic analyzer and second device (that also supports RTS/CTS)
ready so I can measure signals. Maybe there's also software that can
help me test (e.g. to trigger CTS yes/no conditions).
In case I can't easily figure it out: would you also accept a driver
that doesn't support RTS/CTS for its initial version?

On another note: after walking away from the driver for some time I
came back to day and spotted a comment in usb serial core's
usb-serial.c:
> /* we don't use num_ports here because some devices have more endpoint pairs than ports */
With that I'm now setting num_bulk_out to 8 (number of ports) + 1 (for
the config endpoint).
This, together with delaying the call to
usb_serial_generic_write_bulk_callback() until we receive
UART_IIR_THRI allowed me to get rid of the workqueue and re-use a lot
more code from the USB serial core.
In case you're interested what I came up with, you can find the
current code here: [0]


Best regards,
Martin


[0] https://github.com/xdarklight/ch348/blob/90a773410078657c11718821aa45994a7d96712f/ch348.c

Powered by blists - more mailing lists