Messages in this thread |  | | Date | Thu, 15 Aug 2002 11:28:51 -0700 (PDT) | From | Patrick Mochel <> | Subject | RE: [patch] PCI Cleanup |
| |
> ACPI needs access to PCI config space, and it doesn't have a struct pci_dev > to pass to access functions. It doesn't look like your patch exposes an > interface that 1) doesn't require a pci_dev and 2) abstracts the PCI config > access method, does it?
I think your dependencies are backwards. IIRC, and based on a recent conversation, ACPI needs to access PCI config space when ACPI finds a _INI method for a device in the ACPI namespace. That assumes that it can access the root bus that the device is on.
You don't have a PCI device because you haven't implement lockstep enumeration yet in ACPI. With lockstep enumeration, you would add devices to the device tree and let the bus drivers initialize them. With a bit a glue, you would have a pointer to the PCI device correlating to the ACPI namespace object, and a pointer to the PCI bus on which each PCI device/namespace object resides.
To spell it out a bit more explicitly, you would start to parse the ACPI namespace and find a Host/PCI bridge. You would tell the PCI subsystem to probe for a device at that address. It would come back successful, and you would obtain a pointer to that bridge device (and bus object). For all the subordinate devices to that bridge, you then have access to the config space via a real struct pci_bus.
There is no need to modify the PCI interface to support a fake device. The PCI driver needs to be able to add and probe for devices as dictated by someone else, but it's not that difficult.
If you remember, I sent you a patch that did most of this about 5 months ago. It's a bit out of date, and I guarantee that it doesn't apply anymore. But the concept is the same: we should fix the drivers, not hack them to support a broken interface.
-pat
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
|  |