John Youn <john.y...@synopsys.com> 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.

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

Reply via email to