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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <aK7Y9rRIsGBKRFAO@hovoldconsulting.com>
Date: Wed, 27 Aug 2025 12:07:50 +0200
From: Johan Hovold <johan@...nel.org>
To: Martin Blumenstingl <martin.blumenstingl@...glemail.com>
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

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.

> > > > > 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?

Johan