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

Li, Shaohua
2006-06-29T12:41:59Z

>-----Original Message-----
>From: Uwe Bugla [mailto:uwe.bugla@gmx.de]
>Sent: Thursday, June 29, 2006 8:24 PM
>To: Li, Shaohua; bjorn.helgaas@hp.com
>Cc: linux-acpi@vger.kernel.org; Brown, Len; akpm@osdl.org; ambx1@neo.rr.com;
>castet.matthieu@free.fr
>Subject: Re: Re: [patch 11/18] pnpacpi: reject ACPI_PRODUCER resources
>
>
>-------- Original-Nachricht --------
>Datum: Thu, 29 Jun 2006 09:13:36 +0800
>Von: Shaohua Li <shaohua.li@intel.com>
>An: Bjorn Helgaas <bjorn.helgaas@hp.com>
>Betreff: Re: [patch 11/18] pnpacpi: reject ACPI_PRODUCER resources
>
>> 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.
>Hi Shaohua,
>> 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.
>Where is the deeper sense of this discussion as long as the AS-IS-STATE
>conforms to a multiplicity of busses like ISA, PCI, AGP, please?
>And why please didn´t you mix yourself in at an earlier point of time?
>And why don´t you offer more profound material and information on the
>conflicts you saw on your IA64 architecture?
I just took one ia64 box I ever saw as an example, but it's not unique to ia64 I think.

>I simply have big problems understanding the attitude behind your behaviour.
Me too :)

>> > > 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.
>In how far "currently not", please? At what point of time will this make
>sense according to your opinion?
>> We don't expect a PNP driver for root bridge.
>> And we will take risk of buggy BIOS.
>What please has a buggy BIOS to do with a more cryptic or more
>sophisticated ACPI PNP concept?
I want to emphasize I have no objection to merge the producer patch now but still think root bridge should be black list.

Thanks,
Shaohua
-
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html