tech-kern archive

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

Missing ACPI PCI devices in acpi_pcidev_scan


I'm trying to refactor an old ACPI display patch that I sent [1] in dec. 2008, and that I've been using since (on netbsd-5). The patch introduced helper functions to look for a given pci device in the ACPI tree. But, as noted in [2], and I gladly admit it, the implementation was not efficient (it used too many ACPI walks without even caching results). A new implementation now exists in functions acpi_pcidev_scan and acpi_pcidev_find of acpi_pci.c [3], and I would like to use them.

However, acpi_pcidev_scan does not detect all my PCI devices, in fact it only detects one: PCI0. This is due to the fact that the function acpi_pcidev_scan discards devices that do not have the "_BBN" child integer value (PCI bus number). IMHO, PCI devices are not required to have this "_BBN" child, except for PCI host bridges. This is how I interpret the spec, and also what I observe on two PCs (with iasl).

It was previously argued in the list that there should be a unique ACPI namespace walk to build an in-kernel representation of the ACPI tree from which drivers can get all the information they need. I like this idea, but I don't see how acpi_pcidev_scan can find the PCI bus number of PCI devices without the parent-child information of the ACPI tree, and AFAICS this information is currently missing in the in-kernel representation (struct acpi_devnode). As AcpiWalkNamespace performs a DFS (with both pre and post order visitor callbacks), the parent-child information could be stored during the ACPI walk done by acpi_build_tree (in acpi.c), provided that struct acpi_devnode is modified to contain that information. What do you think?

Thanks for your help,



Home | Main Index | Thread Index | Old Index