[patch] xHCI: use gfp flags from caller instead of GFP_ATOMIC

[patch] xHCI: use gfp flags from caller instead of GFP_ATOMIC

[Dan Carpenter]

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.

Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>

diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c
index 6bd9d53..8715cc6 100644
--- a/drivers/usb/host/xhci-ring.c
+++ b/drivers/usb/host/xhci-ring.c
@@ -2734,7 +2734,7 @@ int xhci_queue_intr_tx(struct xhci_hcd *xhci, gfp_t mem_flags,
 				urb->dev->speed = USB_SPEED_FULL)
 			urb->interval /= 8;
 	}
-	return xhci_queue_bulk_tx(xhci, GFP_ATOMIC, urb, slot_id, ep_index);
+	return xhci_queue_bulk_tx(xhci, mem_flags, urb, slot_id, ep_index);
 }
 
 /*
@@ -3514,7 +3514,7 @@ int xhci_queue_isoc_tx_prepare(struct xhci_hcd *xhci, gfp_t mem_flags,
 	}
 	ep_ring->num_trbs_free_temp = ep_ring->num_trbs_free;
 
-	return xhci_queue_isoc_tx(xhci, GFP_ATOMIC, urb, slot_id, ep_index);
+	return xhci_queue_isoc_tx(xhci, mem_flags, urb, slot_id, ep_index);
 }
 
 /****		Command Ring Operations		****/

Re: [patch] xHCI: use gfp flags from caller instead of GFP_ATOMIC

[Sarah Sharp]

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().

Sarah Sharp

> 
> Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
> 
> diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c
> index 6bd9d53..8715cc6 100644
> --- a/drivers/usb/host/xhci-ring.c
> +++ b/drivers/usb/host/xhci-ring.c
> @@ -2734,7 +2734,7 @@ int xhci_queue_intr_tx(struct xhci_hcd *xhci, gfp_t mem_flags,
>  				urb->dev->speed = USB_SPEED_FULL)
>  			urb->interval /= 8;
>  	}
> -	return xhci_queue_bulk_tx(xhci, GFP_ATOMIC, urb, slot_id, ep_index);
> +	return xhci_queue_bulk_tx(xhci, mem_flags, urb, slot_id, ep_index);
>  }
>  
>  /*
> @@ -3514,7 +3514,7 @@ int xhci_queue_isoc_tx_prepare(struct xhci_hcd *xhci, gfp_t mem_flags,
>  	}
>  	ep_ring->num_trbs_free_temp = ep_ring->num_trbs_free;
>  
> -	return xhci_queue_isoc_tx(xhci, GFP_ATOMIC, urb, slot_id, ep_index);
> +	return xhci_queue_isoc_tx(xhci, mem_flags, urb, slot_id, ep_index);
>  }
>  
>  /****		Command Ring Operations		****/

Re: [patch] xHCI: use gfp flags from caller instead of GFP_ATOMIC

[Dan Carpenter]

[-- Attachment #1: Type: text/plain, Size: 786 bytes --]

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 #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [patch] xHCI: use gfp flags from caller instead of GFP_ATOMIC

[Sarah Sharp]

On Fri, Mar 23, 2012 at 08:04:51PM +0300, Dan Carpenter wrote:
> 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.

Ok, now I understand, and I agree.  Please resend the patch with a
better change log and I'll apply it.

Sarah Sharp