Hi, John Youn <John.Youn@xxxxxxxxxxxx> writes: [...] >>>> module parameters also feel like a big, big hammer to hit a tiny nail >>>> head. I don't want to add any module parameters for stuff like this. And >>>> since you've been pushing for them for a while, it only shows that >>>> you're only concerned about your use case ;-) >>> >>> Maybe so, but module params are the easiest, workable solution. It >> >> It might be easy to implement but it becomes a pain as time >> passes. I can give you a concrete example (using device properties to >> illustrate): >> >> We introduced way back a property for platform code to tell us that >> $this dwc3 instance needed the driver to resize FIFOs. The only reason >> for this was because OMAP5 ES1.0 had default FIFO sizes which were less >> than a full bulk USB 3.0 packet (< 1024 bytes) so we couldn't receive >> any USB 3.0 packets. >> >> Documentation was clear that this property was only needed if default >> FIFO sizes were bad and yet several bindings started using it >> blindly. Granted, this is one occasion where it really didn't cause >> problems to resize FIFO, but now imagine what happens when we introduce >> several module parameters and people start using it without really >> knowing what they're for. We will start getting "bug reports" because >> someone passed a e.g. "number_of_endpoints=0" parameter to dwc3 and the >> driver didn't allocate any EP structure, or something silly like that. > > Sure, that's a problem. But you have the same issue with DT bindings > and users setting the wrong things there. I've also had these issues > for dwc2. fair enough :-) > And there are potentially several things we may want to control that > should have no exposure to the user... but we can discuss that when we > get to it :) oh oh >>> doesn't affect any other modules other than dwc3-pci, and they will >>> only touch certain already-defined DT bindings. So in terms of >>> maintainability, the code is all in one place, in one module, and it >>> should be stable since the bindings are already defined as part of the >>> ABI of dwc3.ko. >> >> dwc3-pci is also used by non-FPGA platforms :-) I really don't want to >> introduce module parameters and I really think debugfs can be used here >> for your case. Just expose all parameters you want to dwc3-pci's debugfs >> (needs to be created) and blacklist dwc3.ko so it doesn't load >> automatically. >> >> Then, load dwc3-pci, mount debugfs, set all parameters you need and >> manually modprobe dwc3.ko. No module parameters, debugfs is usually not >> shipping in products, and we can still wrap dwc3-pci's debugfs creation >> with a #ifdef DWC3_FPGA_PROTOTYPE_EXTRAS or something along those lines. > > Ok that should work. > > Do you think it is worth it to create a glue driver just for HAPS with > those settings adjustable only there? it's probably a good idea, then there's even less probability of this leaking into real systems. -- balbi -- 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
