On Tuesday 27 June 2006 19:02, Shaohua Li wrote: > On Tue, 2006-06-27 at 14:02 +0200, castet.matthieu@xxxxxxx wrote: > > Is only PNP0A03 is producer type in __all__ ACPI possible devices ? > > If not we will have the same problem with others devices... > > > > I don't think blacklist is the solution : pnpacpi should be able to handle all > > ressources types : we should complete the implementation instead of blacklist > > devices our implementation doesn't support. > > > > If there are broken ACPI bios, there should be firmware update, a patched dsdt > > or a quirk, but no "quirk and no generic solution". > From my understanding, if the device is really a PNP device its resource > should not be producer. I know PNP as currently implemented doesn't support resource producers. But I don't think of that as a restriction of PNP itself. I think of it as an area where a new back end (PNPACPI) added functionality, and PNP should be enhanced to comprehend it. I think the current scheme where some devices are claimed using PNPACPI and pnp_register_driver(), and others are claimed using acpi_bus_register_driver() directly, is confusing at best. I'd rather have ALL devices handled by PNPACPI, and either extend the PNP infrastructure to comprehend the new functionality of ACPI (e.g., new resource types like PCI bus numbers, ACPI events), or maybe just provide a "to_acpi_dev()" that takes a PNP device and returns the corresponding ACPI device. > Or could we take this way, merge both patches (both patches are good to > me), which should be safer. Anyway, it doesn't make sense to export root > bridge to pnp layer to me. One reason I don't like the blacklist is because it just papers over the problem without leaving a clue about how to really solve it. For example, if PNP is enhanced later to comprehend resource producers, we won't know to go back and remove things from the blacklist. Bjorn - To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
