On Fri, 2006-06-30 at 11:04 +0200, Uwe Bugla wrote: > -------- Original-Nachricht -------- > Datum: Thu, 29 Jun 2006 20:41:07 +0800 > Von: "Li, Shaohua" <shaohua.li@xxxxxxxxx> > An: Uwe Bugla <uwe.bugla@xxxxxx>, bjorn.helgaas@xxxxxx > Betreff: RE: Re: [patch 11/18] pnpacpi: reject ACPI_PRODUCER resources > > > > > > > >-----Original Message----- > > >From: Uwe Bugla [mailto:uwe.bugla@xxxxxx] > > >Sent: Thursday, June 29, 2006 8:24 PM > > >To: Li, Shaohua; bjorn.helgaas@xxxxxx > > >Cc: linux-acpi@xxxxxxxxxxxxxxx; Brown, Len; akpm@xxxxxxxx; > > ambx1@xxxxxxxxxx; > > >castet.matthieu@xxxxxxx > > >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@xxxxxxxxx> > > >An: Bjorn Helgaas <bjorn.helgaas@xxxxxx> > > >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@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. > > >> 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. > Hi Shaohua, > if I got something wrong I´d appreciate you to correct me. > First of all, what is a root bridge please? I know what a PCI-ISA bridge is, but I stumbled across the expression "root bridge." > As a consequence I do not understand in how far this "root bridge" should be blacklisted. > As far as I have received the issue the decision of blacklisting or rejecting ACPI_PRODUCER is a EITHER-OR one, but NOT a ALSO-THIS and ALSO-THAT one. > In so far your path of argumentation is more than confusing, at least for me, and may be for others too. > And as a second consequence I do not understand the essence of proposal or decision you are expecting from Bjorn. > Would be please clear up this?? I gave up, and didn't want to argue this issue any more - 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
