Hi Bjorn, pci-st.c driver could be modular with modification of pcie-designware core driver. But as Fabrice said it should be another patchset. What do you prefer ? drop all the module related macros as mentioned by Paul ? or keep macros like other vendors do ? Thanks Gabriel On 18 March 2015 at 11:35, Paul Bolle <pebolle@xxxxxxxxxx> wrote: > Hi Fabrice, > > Fabrice Gasnier schreef op wo 18-03-2015 om 09:49 [+0100]: >> On 03/16/2015 04:11 PM, Paul Bolle wrote: >> >> +config PCI_ST >> >> + bool "ST PCIe controller" >> > You add a bool Kconfig symbol. A week or two ago I saw some patches fly >> > by that - I think - allowed PCIe controllers to be built modular. >> >> Thanks for your review. >> >> Are you talking about "PCI: Export symbols of PCI functions" patch, that >> is part of a series >> named "pci: iproc: Add Broadcom iProc PCIe support" ? > > Yes, that is the series I was thinking about. (I made you search lkml, > and that was a bit rude. But you found the patch anyhow.) > >> This controller doesn't look like to be based on pcie-designware core >> driver. >> Other vendors that are using "pcie-designware" core driver are also make >> it bool. >> The current core driver doesn't support module loading/unloading as I >> see it. >> If this is required, I also think this should be part of another patchset. >> >> What do you think ? > > I wouldn't know whether your driver might work as a loadable module, but > other people reading this surely will. But if it can't work as a module > you should drop all the module related macros etc. I spotted. Because > then they serve no purpose. > > > Paul Bolle > -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
