On Tue, 29 Sep 2009, Oliver Neukum wrote: > Am Montag, 28. September 2009 20:28:22 schrieb Alan Stern: > > > It's hard to tell. Using flush_scheduled_work() safely is really > > difficult; avoiding it entirely is much easier. > > Do you propose including a work queue usbserial itself doesn't use > into the generic structure for the benefit of subdrivers? At this point I'm not recommending any particular solutions. Mainly I'm recommending that we carefully think things through before acting impulsively. :-) > > 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. > > But that would be a deficiency in the usbserial layer by letting those > through, wouldn't it? Agreed; the usbserial layer should not allow these calls through after the hardware shutdown is complete. But this leaves two questions unresolved: What about calls arriving while the shutdown is in progress? Some drivers might be able to handle them and other drivers might not. What about calls that were already in progress before the shutdown started? To synchronize with them would require taking the mutex on each call or maybe using some form of RCU. Can we afford to do this? Or should we declare that the TTY core is responsible for these things? > > 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. > > Hm. We already have a mutex. Certainly; the question is how best to use it. 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
