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

[David Heidelberg <david@ixit.cz>]

kind ping, I'm still hoping one day we get the driver without need of manual 
building aside.

Thank you for your the efforts you put all into it
David

01/2026 16:31, Johan Hovold wrote:
> 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

-- 
David Heidelberg