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
