On Thu, Jan 11, 2018 at 12:23:25PM -0600, Grant Edwards wrote: > On Thu, Jan 11, 2018 at 06:43:54PM +0100, Greg KH wrote: > > On Thu, Jan 11, 2018 at 11:36:51AM -0600, Grant Edwards wrote: > >> On Thu, Jan 11, 2018 at 08:26:52AM +0100, Greg KH wrote: > >> > >>> You can, but how are you "configuring a particular board"? > >> > >> The thought was that there would be a module parameter that contained > >> sets of "board ID" and config values. What could be used for the > >> "board ID" is the question. Through a bit of trial and error, the > >> user can determine which pci_name (e.g. 0000:07:00.0) belongs to which > >> board. If those names are "stable", then the user could then create a > >> module parameter with the desired configuration value(s) for each > >> pci_name. > > > > Ick, no, don't use module parameters, they do not scale, users never > > know how to use them, they don't work for devices you add after you > > load the module, > > None of the boards in question are hot-pluggable, so that last one > doesn't matter. How do you know that? Any PCI system can "hotplug" PCI devices, with enough effort :) Also, you can soft add/remove PCI devices as well, so your driver has to handle this, as should your userspace solution, if at all possible. > > and all sorts of other problems. This isn't the 1990's anymore :) > > What do you recommend as a means for providing configuration > information to a serial driver for a PCI multi-port serial board? What driver needs configuration? Why can't you determine from userspace using the sysfs tree which PCI device id matches which tty device node? That's all the udev rules do for USB serial devices, I suggest looking at them for ideas of adding this for PCI devices to your 60-serial.rules file in udev. best of luck, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-serial" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
