Am Dienstag, 29. September 2009 19:06:03 schrieb Alan Stern: > 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. :-) Very well. I've now looked at tty code and my head spins. > > > 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. Do they need to handle them? > 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? I am very much in favor of dropping that to the tty layer. > > > 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. Very well. Do we have documentation about mutual exclusion? What can race with what? Regards Oliver -- 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
