Daemon News Ezine BSD News BSD Mall BSD Support Forum BSD Advocacy BSD Updates

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Avoiding probing Host-PCI bridges twice on i386

Ok, I have the following kind of ugly hack to keep the nexus from
probing host-pci bridges when ACPI is found.  It is still a hack
but it works for the same reason that ACPI currently probes PCI
devices ok: ACPI gets its identify routine called first:

Index: pci_bus.c
RCS file: /usr/cvs/src/sys/i386/pci/pci_bus.c,v
retrieving revision 1.83
diff -u -r1.83 pci_bus.c
--- pci_bus.c   2 Aug 2002 18:45:43 -0000       1.83
+++ pci_bus.c   30 Aug 2002 13:19:03 -0000
@@ -290,7 +290,7 @@
        int found_orion = 0;
        int found_pcibios_flaming_death = 0;
        device_t child;
-       devclass_t pci_devclass;
+       devclass_t devclass;
        if (pci_cfgregopen() == 0)
@@ -299,10 +299,17 @@
         * via some other means.  If we have, bail since otherwise
         * we're going to end up duplicating it.
-       if ((pci_devclass = devclass_find("pci")) && 
-               devclass_get_device(pci_devclass, 0))
+       if ((devclass = devclass_find("pci")) && 
+               devclass_get_device(devclass, 0))
+               return;
+       /*
+        * Check to see if the ACPI identify routine succeeded.  If so,
+        * ACPI will find any host-PCI bridges so don't duplicate them
+        * here.
+        */
+       if ((devclass = devclass_find("acpi")) &&
+               devclass_get_device(devclass, 0))
        bus = 0;

I think, though, that really we should reorganize things a bit
so that ACPI works right, not just by chance.  We really need to
somehow probe ACPI first, and then if it's identify routine
(which is really a probe of an ACPI nexus-like device) fails,
then we do the other nexus identifies.  ACPI really is more of
an alternate nexus almost.  Perhaps on the i386 what we need
is a kind of system-board/bus driver that attaches to the nexus.
ACPI would be one driver, and a new driver would be made up of
stuff that is currently in the nexus.  I.e., if the ACPI probe
fails, then our other driver's probe will succeed (maybe it is
called system0 or something) and the system bus would be the
one that the pci bus driver in sys/i386/pci/pci_bus.c would
actually be an identify routine of.  Does this make any sense?


John Baldwin <jhb@xxxxxxxxxxx>  <><  http://www.FreeBSD.org/~jhb/
"Power Users Use the Power to Serve!"  -  http://www.FreeBSD.org/

To Unsubscribe: send mail to majordomo@xxxxxxxxxxx
with "unsubscribe freebsd-new-bus" in the body of the message