> > > 0006-fpga-dfl-add-support-for-N3000-Nios-private-feature.patch > > > - module parameters are for drivers written in the > > > 1990's. Please just "do the right thing" and make the > > > code work properly without having to have custom > > > options. Note this option does not really work if you > > > have multiple devices in the system at once, which is > > > one reason why we don't use module parameters anymore. > > > > I'm wondering which is the better way to handle the case, but let me > > first describe it. > > > > The n3000-nios driver will first require the embedded firmware to > > finish some netdev configuration (via the SPI controller) according to > > user's option, then the driver takes over the control of the SPI > > controller and continue to enumerate various devices behind the SPI bus. > > The firmware will never be active again after the first configuration on > > power cycle. So I tend to let the driver finish the configuration > > requirement at probe, then the following drivers for SPI devices could be > > autoloaded. This is why I choose the module parameter. > > Remember, module parameters affect ALL devices the driver controls, you > just broke the ability for this driver to handle multiple devices per a > single driver, with no way of ever fixing that (module parameters are > userspace apis...) > > > I was considering the sysfs interface option to trigger this one-time > > configuration. But this makes the SPI devices unavailable until user > > inputs something to this sysfs node. We may need to add some specific > > udev rules to make the whole functionalities of the FPGA card enabled > > automatically. > > Why can't you figure out the state of the device without having to worry > about a module option? No one will know how to set that thing, and if > they do, it will get baked into a bootloader somewhere and no one can > ever turn it off. It's the discrete hot-plugable PCIe card which is not managed in host bootloader. And because of the HW design, the onboard firmware doesn't get a writable non-volatile memory for the options, so it needs the input from user. Anyway, I need to reconsider this solution. But I got learned that "don't make the user have to configure something out of their scope". Thanks very much, Yilun > > Be dynamic and make things "just work" so that the user does not have to > configure anything at all please. > > > And our customers don't expect different configurations between > > multiple cards on one system, which also influences my decision. > > They might not say that today, but you just forced them to never be able > to do that ever, in the next 20+ years :( > > thanks, > > greg k-h
