* Bin Liu <b-...@ti.com> [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 <t...@atomide.com> > > > > > > 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 <t...@atomide.com> > > > Signed-off-by: Bin Liu <b-...@ti.com> > > > --- > > > 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html