On 9/20/20 9:52 PM, Kishon Vijay Abraham I wrote: > Hi Randy, > > On 18/09/20 9:45 pm, Randy Dunlap wrote: >> On 9/17/20 11:42 PM, Kishon Vijay Abraham I wrote: >>> diff --git a/drivers/ntb/hw/epf/Kconfig b/drivers/ntb/hw/epf/Kconfig >>> new file mode 100644 >>> index 000000000000..6197d1aab344 >>> --- /dev/null >>> +++ b/drivers/ntb/hw/epf/Kconfig >>> @@ -0,0 +1,6 @@ >>> +config NTB_EPF >>> + tristate "Generic EPF Non-Transparent Bridge support" >>> + depends on m >>> + help >>> + This driver supports EPF NTB on configurable endpoint. >>> + If unsure, say N. >> >> Hi, >> Why is this driver restricted to 'm' (loadable module)? >> I.e., it cannot be builtin. > > I'm trying to keep all the host side PCI drivers corresponding to the > devices configured using endpoint function drivers as modules and also > not populate MODULE_DEVICE_TABLE() to prevent auto-loading. > > The different endpoint function drivers (right now only pci-epf-test.c > and pci-epf-ntb.c) can use the same device ID and vendorID for > configuring the endpoint devices. So on the host side, it's possible an > un-intended PCI driver can be bound to the device. So in-order to give > users the flexibility of deciding the driver to be bound, I'm trying to > keep it as modules. (Some driver like NTB also uses class code > PCI_CLASS_MEMORY_RAM for binding a driver in addition to deviceID and > vendorID but it need not be the case for all the drivers.) Thanks for the explanation. -- ~Randy
