On Thu, Feb 21, 2013 at 07:33:45PM +0000, Paul Zimmerman wrote: > > -----Original Message----- > > From: Felipe Balbi [mailto:ba...@ti.com] > > Sent: Thursday, February 21, 2013 12:58 AM > > > > On Thu, Feb 21, 2013 at 03:22:54AM +0000, Paul Zimmerman wrote: > > > Building and validating a new FPGA image is a lengthy task. If I can make > > > things work by tweaking some module parameters, so much the better. > > > Plus, as part of our validation testing we try with different values for > > > things > > > like FIFO sizes and DMA modes. Building a new FPGA image to tweak > > > stuff like that is just not practical. > > > > Is there at least part of that stuff which you could just do by default > > without relying on a module parameter ? I mean, if you know default > > value is bogus, can you not compute a good value in runtime and just > > use it ? > > > > I mean, the amount of module parameters in this driver is much more than > > anyone will be able to understand and use correctly. You really want to > > decrease the amount of module parameters. dwc3, for instance, has a > > single module parameter which is used for testing purposes only (forcing > > the IP to work on lower speeds). MUSB has 3 module parameters only, > > net2272 has 4... anyway, usually anything bigger than 4 to 5 module > > parameters will already cause problems, specially on cases where loading > > the driver without any module parameter is likely to not work. > > I can pare the user-visible module parameters down to 6, that would > give us most of what we need for testing purposes. The remainder I > can leave in the parameter struct, so they can be tweaked at build time, > but not add module_param() calls for them. How does that sound?
Not good, you shouldn't have any module parameters if at all possible. As you are saying you only need them for "testing", they why not put them in dynamic files, like debugfs, instead? thanks, greg k-h -- 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
