linux-kernel - Re: [PATCH 1/1 v7] 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: <Z4kfqwCrO6q6oqtL@hovoldconsulting.com>
Date: Thu, 16 Jan 2025 16:03:07 +0100
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 1/1 v7] usb: serial: add support for CH348

On Tue, Jan 14, 2025 at 10:40:56PM +0100, Martin Blumenstingl wrote:

> > Not sure what Corentin has been preparing, but yeah, you need some kind
> > of deferred mechanism to make write() non-blocking and hold off sending
> > more data to the device until you're sure there's room in its buffers. I
> > guess a workqueue should do fine.

> We're currently testing an updated driver based on a workqueue
> (work_struct) and it's working fine.
> The issue that Corentin reported is unrelated to the workqueue part.
> At this point we're thinking it may be a regression in linux-next, but
> we're running more tests to verify this.

You don't need to test the driver against linux-next, rc7 should do just
fine for a driver like this.

Let's see what the new implementation looks like. Perhaps you don't even
need to use a workqueue (e.g. send off the single URB from the
completion callback when you get a notification that the transmitter has
emptied).

Johan