On Tue, Jun 28, 2011 at 08:38:15PM +0300, Felipe Balbi wrote: > hi, > > On Tue, Jun 28, 2011 at 08:37:58AM -0700, Greg KH wrote: > > On Tue, Jun 28, 2011 at 04:33:45PM +0300, Felipe Balbi wrote: > > > Hi Greg, > > > > > > here's the pull request for USB Gadget and MUSB. > > > > > > I just tested these changes with MUSB and thus far > > > everything seems ok. I had a few last minute issues > > > with MUSB but they are fixed on this pull request. > > > > > > Like noted before on the announcement I made [1] we > > > have one small known regression with MUSB regarding > > > a module parameter which shouldn't really exist. > > > > I don't like having known problems like this. Why do we now have to > > fair enough. > > > have a module parameter where we didn't before? And who is going to > > The module has always been there, what changed is its default value > which is set based on an ugly architecture-based ifdef: Yes, but now you are changing the default value on some platforms and forcing them to use a module paramater where they previously were not. That's not nice. > 1012 #if defined(CONFIG_USB_MUSB_TUSB6010) || defined(CONFIG_USB_MUSB_OMAP2PLUS) \ > 1013 || defined(CONFIG_USB_MUSB_AM35X) > 1014 static ushort __initdata fifo_mode = 4; > 1015 #elif defined(CONFIG_USB_MUSB_UX500) > 1016 static ushort __initdata fifo_mode = 5; > 1017 #else > 1018 static ushort __initdata fifo_mode = 2; > 1019 #endif > 1020 > 1021 /* "modprobe ... fifo_mode=1" etc */ > 1022 module_param(fifo_mode, ushort, 0); > 1023 MODULE_PARM_DESC(fifo_mode, "initial endpoint configuration"); > > I decided it would be way uglier to add corresponding _MODULE version > for each glue layer and left as is so that I force myself (and others) > to make this work reliably. But you just broke those users. No matter how much you want to force yourself, you should fix it even in a messy way now. So, please respin these to not cause this kind of breakage. thanks, greg k-h -- 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
