Randy Dunlap wrote: > Cui, Dexuan wrote: >> Randy Dunlap wrote: >>> On Fri, 18 Dec 2009 16:49:48 +0800 Dexuan Cui wrote: >>> >>>> When CONFIG_PCI_QUIRKS=n, the kernel build fails: >>>>> drivers/built-in.o: In function `pci_dev_reset': >>>>> pci.c:(.text+0xdb0b): undefined reference to >>>>> `pci_dev_reset_methods' pci.c:(.text+0xdb2b): undefined reference >>>>> to `pci_dev_reset_methods' pci.c:(.text+0xdb85): undefined >>>>> reference to `pci_dev_reset_methods' >>>> We should add a dummy pci_dev_reset_methods[] in this case. >>> OK, that works. I admit that I would have just made a stub for >>> pci_dev_specific_reset() in pci.c instead, or just put the >>> data struct and for-loop inside #ifdef CONFIG_PCI_QUIRKS/#endif. >> >> Can CONFIG_PCI_QUIRKS appear in pci.c? I'm not sure. :-) > > Sure it can. OK. So, I prefer this way because it requires only 2 "#ifndef CONFIG_PCI_QUIRKS #endif" checks. > >> Or, can we move the pci_dev_specific_reset() into pci.h and make it >> "static inline", and if "#ifndef CONFIG_PCI_QUIRKS" it just does >> nothing and "return -ENOTTY"? >> >> Which is the best? Please comment. > > I'm not sure that there is a "best". Your patch isn't wrong. > However, now that I've looked at it again, here's what I would do: > > move pci_dev_specific_reset() into quirks.c and have 2 versions of it > there. One inside #ifdef CONFIG_PCI_QUIRKS (the function as it is now) > and one version of it after the #else (for CONFIG_PCI_QUIRKS disabled) > that just returns -ENOTTY. > Thanks a lot for the suggestion. However this needs a much more lines of patch, and we have to declare pci_dev_specific_reset() in some header file, like pci.h. So I think your original suggestion is better as I replied above, and I'll post a patch for that. Please have a look. Thanks, -- Dexuan -- 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