* Bin Liu <b-liu@xxxxxx> [170103 10:35]:
> Tony,
>
> On Tue, Jan 03, 2017 at 04:36:14PM +0100, Greg KH wrote:
> > On Tue, Jan 03, 2017 at 09:15:08AM -0600, Bin Liu wrote:
> > > From: Tony Lindgren <tony@xxxxxxxxxxx>
> > >
> > > When unloading omap2430, we can get the following splat:
> > >
> > > WARNING: CPU: 1 PID: 295 at kernel/irq/manage.c:1478 __free_irq+0xa8/0x2c8
> > > Trying to free already-free IRQ 4
> > > ...
> > > [<c01a8b78>] (free_irq) from [<bf0aea84>]
> > > (musbhs_dma_controller_destroy+0x28/0xb0 [musb_hdrc])
> > > [<bf0aea84>] (musbhs_dma_controller_destroy [musb_hdrc]) from
> > > [<bf09f88c>] (musb_remove+0xf0/0x12c [musb_hdrc])
> > > [<bf09f88c>] (musb_remove [musb_hdrc]) from [<c056a384>]
> > > (platform_drv_remove+0x24/0x3c)
> > > ...
> > >
> > > This is because the irq number in use is 260 nowadays, and the dma
> > > controller is using u8 instead of int.
> > >
> > > Signed-off-by: Tony Lindgren <tony@xxxxxxxxxxx>
> > > Signed-off-by: Bin Liu <b-liu@xxxxxx>
> > > ---
> > > drivers/usb/musb/musbhsdma.h | 2 +-
> > > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > Is this a new thing?
> >
> > >
> > > diff --git a/drivers/usb/musb/musbhsdma.h b/drivers/usb/musb/musbhsdma.h
> > > index f7b13fd25257..a3dcbd55e436 100644
> > > --- a/drivers/usb/musb/musbhsdma.h
> > > +++ b/drivers/usb/musb/musbhsdma.h
> > > @@ -157,5 +157,5 @@ struct musb_dma_controller {
> > > void __iomem *base;
> > > u8 channel_count;
> > > u8 used_channels;
> > > - u8 irq;
> > > + int irq;
> >
> > Is this a regression? Needs to go to older kernels? What caused this
> > issue?
>
> Is it possible to add a cc stable or Fixes tag?
I think it's been there since the beginning. At some point the IRQ numbering
changed exposing the issue and the overflow started happening, but nobody
obviously tested this as a loadable module. So unfortunately no fixes tag
can be easily found.
OK to Cc stable though to avoid the overflow.
Regards,
Tony
--
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
