On Fri, Mar 23, 2012 at 09:29:57AM -0700, Sarah Sharp wrote: > On Fri, Mar 23, 2012 at 03:09:00PM +0300, Dan Carpenter wrote: > > We're not holding a lock here so we can use the gfp flags the caller > > specifies instead of GFP_ATOMIC. The callers use GFP_ATOMIC so this > > change doesn't affect how the kernel runs, but it's a cleanup. > > Nak. We are holding a lock in all the xhci_queue* functions, so we > need GFP_ATOMIC. It's locked in a parent function, xhci_urb_enqueue(). > Sorry, bad changlog on my part. I saw that it was locked in the parent, but I meant that it's not taking a lock here. The parent specifies GFP_ATOMIC so the parent is fine. I don't think we should bother passing the GFP flags if we don't use them. regards, dan carpenter
Attachment:
signature.asc
Description: Digital signature