On Thu, Apr 11, 2013 at 4:06 PM, Bjørn Mork <bjorn@xxxxxxx> wrote: > Oliver Neukum <oliver@xxxxxxxxxx> writes: > > My immediate thought was that someone also might want to use this new > API from atomic context, e.g. calling it directly from an URB callback. I am wondering it is a valid use case, and if there is one URB submitted, the interrupt URB for status has been submitted already, hasn't it? > But that is of course not possible taking a mutex. Could the lock > preventing interrupt_count maybe be a spinlock instead? Or am I on the > completely wrong track here? Also it is a bit odd that the 'start' API is allowed in atomic context, but the 'stop' API isn't allowed, and it is very easy to cause unbalanced counter. > > In any case, I don't see the point unnecessarily limiting the API by > dropping the memflags. What possible problem would that solve? If you think 'start' API should be called in atomic context, the memflags should be always 'GFP_ATOMIC'. I let Oliver explain why GFP_NOIO is needed in other cases. Thanks -- Ming Lei -- 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
