Re: [patch 11/18] pnpacpi: reject ACPI_PRODUCER resources

[Shaohua Li <shaohua.li@intel.com>]

On Wed, 2006-06-28 at 10:55 -0600, Bjorn Helgaas wrote:
> On Tuesday 27 June 2006 19:02, Shaohua Li wrote:
> > On Tue, 2006-06-27 at 14:02 +0200, castet.matthieu@free.fr 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.
Ok, it's fine ACPI PNP handles resource producers.

> 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.
That's a big deal. We had a lot of discussions about this like
introducing ACPI bus, but frankly there isn't a solid direction which
bus ACPI devices should belong to.

> > 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.
So lets have a note there. It (no blacklist) is meaningful to have all
ACPI devices handled by PNP layer, but currently not. We don't expect a
PNP driver for root bridge. And we will take risk of buggy BIOS.

Thanks,
Shaohua