On Mon, Oct 10, 2011 at 9:17 AM, Prarit Bhargava <prarit@xxxxxxxxxx> wrote: > >> >> what is the point sriov=1? are you going to enable sriov forcefully? >> >> pci=nosriov > > Hi Yinghai, > > I'm looking at this from a distribution's point-of-view. > > SRIOV is built-in but purposely disabled by the distro for a particular system via an SMBIOS check so that pci_sriov_enabled = 0. > > In that case, when the system was functional, through a FW update, I will want to turn it on without having to rebuild the kernel. ie) specifying pci=sriov=1 makes sense to test or debug in that case. > > If that isn't acceptable to upstream, I would have no objection to pci=nosriov. What about pci=sriov pci=nosriov The existing PCI options that use "=" are mostly things that require an entire value (bitmask, size, etc.) rather than just a boolean, and there's some precedent for using "OPTION and noOPTION" for boolean things (bios/nobios, rom/norom, bfsort/nobfsort). Would you mind mentioning "PCI" in the printk message along with "SRIOV" just to help dmesg readers put it in context? Would it be overkill to mention either in Documentation/kernel-parameters.txt or in the dmesg that if you needed to use this option, you should report a bug? I've been disappointed by how many times I've found reports on the web saying "pci=use_crs" is the final fix, when it's really only a band-aid that we should fix properly in the kernel. I don't think end-users should ever have to know about options like this, but sometimes they become part of the folklore of random things that people try, which reflects poorly on Linux. Bjorn -- To unsubscribe from this list: send the line "unsubscribe linux-pci" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
