Re: [PATCH v8 1/2] usb: serial: add support for CH348

[Johan Hovold <johan@kernel.org>]

On Mon, Dec 15, 2025 at 03:10:29AM +0100, Martin Blumenstingl wrote:
> On Mon, Dec 1, 2025 at 3:10 PM Johan Hovold <johan@kernel.org> wrote:

> > > 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)?
> >
> > You can try disabling reading from the device (e.g. never submit the
> > read urbs) and see if the RTS is deasserted when the buffer fills up.

> Doing so results in:
> - lots of UART_LSR_OE
> - RTS stays LOW (pulled to GND)
> 
> UART_LSR_OE increasing seems correct as far as I understand this.
> RTS being LOW is wrong and I cannot manage to get ch348 to pull it to HIGH.
> 
> I did some more research and found that ch348 implements UART_IIR_MSI
> and provides a fully standard compatible UART_MSR.
> This is either triggered by a status change on the pins (UART_MSR
> delta bits and the actual status bits), or by requesting an update
> using the VEN_R command (UART_MSR status bits only, no delta bits).
> 
> In a very simple test-case I've used jumper cables on port #0 of ch348:
> - RX and TX connected together
> - CTS and RTS connected together
> 
> If I remove the jumper between CTS and RTS I get:
>   ch348 ttyUSB0: got MSR = 0x01 // jumper removed
>   ch348 ttyUSB0: got MSR = 0x11 // jumper connected again
>   ch348 ttyUSB0: got MSR = 0x01 // jumper removed again
> 
> So the hardware does register the change.
> 
> Earlier I thought I found a fix: I had the values for
> R_C4_HW_FLOW_CONTROL_OFF and R_C4_HW_FLOW_CONTROL_ON swapped.
> That however didn't fix it.
> 
> My current work can be found here: [0]
> If you also don't have any further ideas then I'll drop the whole
> RTS/CTS code for now so the ch348 driver can finally make it into
> Linux 6.20

Or you can include it and just document the known issue with RTS control
for port 1. It seems you have everything else working, right?

> > And in the other direction, verify that writes are buffered after you
> > deassert RTS manually on the other end. That should be easier.

> This seems to work: if I pull CTS up then ch348 stops sending data

So that means hardware flow control (CRTSCTS) is enabled, which could
prevent manual control of RTS. Which port did you test this on? Or is it
the same behaviour on all ports (0-3)?

Going back to archives, it seems like you can control RTS on ports 0, 2
and 3. (And DTR/RTS is not available for ports 4-7).

Hardware flow being enabled on just port 1 may explain the difference
even if you would expect the device to also deassert RTS in the overflow
test (unless there are separate bits for controlling auto-rts and
auto-cts).

> > > 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?
> >
> > It's good to at least be able to control DTR/RST at open/close (i.e.
> > implement dtr_rts()) so that you can communicate when the other end
> > has hw flow enabled. Sound like you're really close to doing so.

> In the meantime I found out why I had trouble with the DTR signal on port 1.
> It was a user(space) error. I've been using [1] for some of my tests
> and it has a bug where it would clear c_cflag HUPCL [2], which
> prevents the kernel from turning DTR off on port close.

Ah, good that you found that.

Johan