>-----Original Message----- >From: Mike Frysinger [mailto:vapier.adi@xxxxxxxxx] >Sent: Wednesday, March 17, 2010 11:26 PM >To: Sergei Shtylyov >Cc: linux-usb@xxxxxxxxxxxxxxx; felipe.balbi@xxxxxxxxx; >gregkh@xxxxxxx; Cai, Cliff >Subject: Re: [PATCH] MUSB: Blackfin: don't fake >blackfin_interrupt() result > >On Tue, Mar 16, 2010 at 11:20, Sergei Shtylyov wrote: >> Commit a5073b52833e4df8e16c93dc4cbb7e0c558c74a2 (musb_gadget: fix >> unhandled endpoint 0 IRQs) misses this change to blackfin.c: stop >> faking successful result of blackfin_interrupt() and >emitting a debug >> message on an unhandled interrupt. >> >> Signed-off-by: Sergei Shtylyov <sshtylyov@xxxxxxxxxx> >> >> --- >> The patch is against the recent Linus' tree. >> >> Mike, the comment metions BF54x -- was there some specific case of >> unhandled interrupts with it, so you'd prefer to keep DBG()? > >we did initial Blackfin MUSB development against the BF54x, so >i dont believe the explicit mention of it here is terribly relevant > >i think this should be OK, but i'm not the USB guy, so Cliff >can double check / Ack the patch -mike > >> drivers/usb/musb/blackfin.c | 8 +------- >> 1 file changed, 1 insertion(+), 7 deletions(-) >> >> Index: linux-2.6/drivers/usb/musb/blackfin.c >> =================================================================== >> --- linux-2.6.orig/drivers/usb/musb/blackfin.c >> +++ linux-2.6/drivers/usb/musb/blackfin.c >> @@ -173,13 +173,7 @@ static irqreturn_t blackfin_interrupt(in >> >> spin_unlock_irqrestore(&musb->lock, flags); >> >> - /* REVISIT we sometimes get spurious IRQs on g_ep0 >> - * not clear why... fall in BF54x too. >> - */ >> - if (retval != IRQ_HANDLED) >> - DBG(5, "spurious?\n"); >> - >> - return IRQ_HANDLED; >> + return retval; >> } >> >> static void musb_conn_timer_handler(unsigned long _musb) >> > Looks good to me,if the IRQ is spurious,returning IRQ_NONE is better than returning IRQ_HANDLED. Thanks. Acked-by: Cliff Cai <cliff.cai@xxxxxxxxxx> -- 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
