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? > 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? > This includes special-purpose URBs, like those used for changing baud > rates and so on, not just the normal data-in/data-out URBs. Agreed. > 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. Therefore the driver must be notified before URBs are killed or poisoned. > 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. 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
