On Mon, 15 Oct 2012, Oliver Neukum wrote: > On Friday 12 October 2012 11:29:49 Alan Stern wrote: > > On Fri, 12 Oct 2012, Oliver Neukum wrote: > > > > First we have workqueues. bas-gigaset is a good example. > > > The driver kills a scheduled work in pre_reset(). If this is done synchronously > > > the driver may need to wait for a memory allocation inside the work. > > > In principle we could provide a workqueue limited to GFP_NOIO. Is that worth > > > it, or do we just check? > > > > The work routine could set the GFP mask upon entry and exit. Then a > > separate workqueue wouldn't be needed. > > Well, yes. But if we have to touch the code we might just as well use GFP-NOIO Depends on what the code does. If it does very little requiring memory allocation then yes, you could simply use GFP_NOIO. But if it calls lots of other routines that all do their own allocation, setting the mask will be better. > > > I am afraid there is no generic solution in the last two cases. What do you think? > > > > The other contexts must also set the GFP mask. Unfortunately, this has > > to be done case-by-case. > > This raises a question. If we do the port-power-off stuff, does reset_resume() of every > device under the depowered port have to be called? Certainly. > If so, we cannot exclude vendor > specific drivers from the audit, can we? True. But hasn't that always been the case? A device could need a vendor-specific driver for one interface while another interface uses a standard mass-storage protocol. 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
