In the past PCI front-end would be booted as part of the subsystem.
That was OK as the XenBus was started at that point as well.
But with the recent kernels XenBus is initialized much later and the
the registration of the PCI bus would miserably fail (BUG). This
fixes that issue.
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>
---
drivers/pci/Kconfig | 7 ++++---
drivers/pci/xen-pcifront.c | 13 ++++++++++---
2 files changed, 14 insertions(+), 6 deletions(-)
diff --git a/drivers/pci/Kconfig b/drivers/pci/Kconfig
index 97a59d5..3a858a8 100644
--- a/drivers/pci/Kconfig
+++ b/drivers/pci/Kconfig
@@ -52,10 +52,11 @@ config PCI_STUB
When in doubt, say N.
config XEN_PCIDEV_FRONTEND
- bool "Xen PCI Frontend"
- depends on PCI && X86_64
+ tristate "Xen PCI Frontend"
+ depends on XEN && PCI && X86_64
select HOTPLUG
- default y
+ select XEN_XENBUS_FRONTEND
+ default y
help
The PCI device frontend driver allows the kernel to import arbitrary
PCI devices from a PCI backend to support PCI driver domains.
diff --git a/drivers/pci/xen-pcifront.c b/drivers/pci/xen-pcifront.c
index 854850d..8ec3aca 100644
--- a/drivers/pci/xen-pcifront.c
+++ b/drivers/pci/xen-pcifront.c
@@ -1094,7 +1094,6 @@ static const struct xenbus_device_id xenpci_ids[] = {
{"pci"},
{{0}},
};
-MODULE_ALIAS("xen:pci");
static struct xenbus_driver xenbus_pcifront_driver = {
.name = "pcifront",
@@ -1113,5 +1112,13 @@ static int __init pcifront_init(void)
return xenbus_register_frontend(&xenbus_pcifront_driver);
}
-/* Initialize after the Xen PCI Frontend Stub is initialized */
-subsys_initcall(pcifront_init);
+static void __exit pcifront_cleanup(void)
+{
+ xenbus_unregister_driver(&xenbus_pcifront_driver);
+}
+module_init(pcifront_init);
+module_exit(pcifront_cleanup);
+
+MODULE_DESCRIPTION("Xen PCI passthrough frontend.");
+MODULE_LICENSE("GPL");
+MODULE_ALIAS("xen:pci");
--
1.6.2.5
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|