Hi,
> Hi,
>
> On Thu, Mar 12, 2015 at 05:40:56AM +0000, yoshihiro shimoda wrote:
> > Hi,
> >
< snip >
> > >
> > > try something like below:
> > >
> > > diff --git a/drivers/usb/renesas_usbhs/mod_gadget.c b/drivers/usb/renesas_usbhs/mod_gadget.c
> > > index e0384af77e56..e9d75d85be59 100644
> > > --- a/drivers/usb/renesas_usbhs/mod_gadget.c
> > > +++ b/drivers/usb/renesas_usbhs/mod_gadget.c
> > > @@ -119,7 +119,7 @@ struct usbhsg_recip_handle {
> > > /*
> > > * queue push/pop
> > > */
> > > -static void usbhsg_queue_pop(struct usbhsg_uep *uep,
> > > +static void __usbhsg_queue_pop(struct usbhsg_uep *uep,
> > > struct usbhsg_request *ureq,
> > > int status)
> > > {
> > > @@ -133,6 +133,15 @@ static void usbhsg_queue_pop(struct usbhsg_uep *uep,
> > > usb_gadget_giveback_request(&uep->ep, &ureq->req);
> > > }
> > >
> > > +static void usbhsg_queue_pop(struct usbhsg_uep *uep,
> > > + struct usbhsg_request *ureq,
> > > + int status)
> > > +{
> > > + usbhs_lock(priv, flags);
> > > + __usbhsg_queue_pop(uep, ureq, status);
> > > + usbhs_unlock(priv, flags);
> > > +}
> > > +
> > > static void usbhsg_queue_done(struct usbhs_priv *priv, struct usbhs_pkt *pkt)
> > > {
> > > struct usbhs_pipe *pipe = pkt->pipe;
> > >
> > >
> > > then, for cases where lock is already held you call __usbhsg_queue_pop()
> > > and for all other cases, call usbhsg_queue_pop().
> >
> > Thank you for the suggestion. However, we cannot use this
> > usbhsg_queue_pop() because a gadget driver might call usb_ep_queue()
> > in the "complete" function and this driver calls usbhs_lock() in the
> > usb_ep_queue().
>
> right, in that case just call __usbhs_queue_pop() directly.
Yes. So, my understanding is that this driver always calls __usbhs_queue_pop()
because this driver cannot know that a gadget driver calls usb_ep_queue() or not
in the "complete" function.
> > Perhaps my explanation was bad, but this issue was caused by the
> > following conditions:
> > - I use the renesas_usbhs driver as udc.
> > - I use an old usb-dmac driver that the callback runs on a kthread.
> > - I use the ncm driver. In this environment, the ncm driver might
> > cause a spinlock suspected.
> >
> > As an old solution, I fixed the renesas_usbhs driver by this patch.
> > However, if I use a new usb-dmac driver that the callback runs on a
> > tasklet, I don't need this patch. (This is a new solution.)
>
> then differentiate based on some revision register or something like
> that ?
Sorry for the lack information. I am submitting this usb-dmac driver that
the callback runs on a tasklet now. This means that the driver is not
merged yet. So, I think that we don't need to differentiate.
Best regards,
Yoshihiro Shimoda
> --
> balbi
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
