* [patch] xHCI: use gfp flags from caller instead of GFP_ATOMIC
@ 2012-03-23 12:09 Dan Carpenter
2012-03-23 16:29 ` Sarah Sharp
` (2 more replies)
0 siblings, 3 replies; 4+ messages in thread
From: Dan Carpenter @ 2012-03-23 12:09 UTC (permalink / raw)
To: kernel-janitors
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 ****/
^ permalink raw reply related [flat|nested] 4+ messages in thread* Re: [patch] xHCI: use gfp flags from caller instead of GFP_ATOMIC
2012-03-23 12:09 [patch] xHCI: use gfp flags from caller instead of GFP_ATOMIC Dan Carpenter
@ 2012-03-23 16:29 ` Sarah Sharp
2012-03-23 17:04 ` Dan Carpenter
2012-03-26 18:46 ` Sarah Sharp
2 siblings, 0 replies; 4+ messages in thread
From: Sarah Sharp @ 2012-03-23 16:29 UTC (permalink / raw)
To: kernel-janitors
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 ****/
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [patch] xHCI: use gfp flags from caller instead of GFP_ATOMIC
2012-03-23 12:09 [patch] xHCI: use gfp flags from caller instead of GFP_ATOMIC Dan Carpenter
2012-03-23 16:29 ` Sarah Sharp
@ 2012-03-23 17:04 ` Dan Carpenter
2012-03-26 18:46 ` Sarah Sharp
2 siblings, 0 replies; 4+ messages in thread
From: Dan Carpenter @ 2012-03-23 17:04 UTC (permalink / raw)
To: kernel-janitors
[-- 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 --]
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [patch] xHCI: use gfp flags from caller instead of GFP_ATOMIC
2012-03-23 12:09 [patch] xHCI: use gfp flags from caller instead of GFP_ATOMIC Dan Carpenter
2012-03-23 16:29 ` Sarah Sharp
2012-03-23 17:04 ` Dan Carpenter
@ 2012-03-26 18:46 ` Sarah Sharp
2 siblings, 0 replies; 4+ messages in thread
From: Sarah Sharp @ 2012-03-26 18:46 UTC (permalink / raw)
To: kernel-janitors
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
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2012-03-26 18:46 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2012-03-23 12:09 [patch] xHCI: use gfp flags from caller instead of GFP_ATOMIC Dan Carpenter
2012-03-23 16:29 ` Sarah Sharp
2012-03-23 17:04 ` Dan Carpenter
2012-03-26 18:46 ` Sarah Sharp
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox