On Mon, 28 Sep 2009, Oliver Neukum wrote: > Am Donnerstag, 24. September 2009 23:32:39 schrieb Johan Hovold: > > > You can, if you wish to hide what's going on, poison the urb. The > > > correct sequence is: > > > > > > 1. poison the urb > > > 2. cancel_delayed_work_sync > > > > > > 3. unpoison the urb > > > > <snip> > > > > > Step 1 sets a flag. > > > > And this is what we generally want to be doing I assume, rather than > > adding an explicit state flag? > > If we do this we might just as well do it generically. > Alan, this uses flush_scheduled_work() prone to deadlocks. > I think I used it safely in this patch. Could you check? It's hard to tell. Using flush_scheduled_work() safely is really difficult; avoiding it entirely is much easier. I would prefer to see a scheme that was well considered and planned out in advance, something that would work properly for all the USB serial drivers, even if it meant updating a bunch of them. The issue appears to boil down to this: When shutting down the hardware, _all_ the URBs have to be unlinked and no new ones may be submitted. This means the lower-level serial driver must not communicate with the device, even though the serial core might call subroutines which wish to do so. This includes special-purpose URBs, like those used for changing baud rates and so on, not just the normal data-in/data-out URBs. The subtle aspect here is that communication may be okay _during_ the shutdown procedure -- the requirement applies only after the shutdown is completed. But there's no way for usb-serial to know how the driver wants to handle things, so the decisions have to be made in the driver. This implies a need for some kind of synchronization between usb-serial and the driver. But what form that should take, I don't know. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
