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

["Uwe Bugla" <uwe.bugla@gmx.de>]

-------- Original-Nachricht --------
Datum: Thu, 29 Jun 2006 20:41:07 +0800
Von: "Li, Shaohua" <shaohua.li@intel.com>
An: Uwe Bugla <uwe.bugla@gmx.de>, bjorn.helgaas@hp.com
Betreff: RE: Re: [patch 11/18] pnpacpi: reject ACPI_PRODUCER resources

> 
> 
> >-----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.
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??
> 
> Thanks,
> Shaohua
Regards
Uwe

-- 


"Feel free" – 10 GB Mailbox, 100 FreeSMS/Monat ...
Jetzt GMX TopMail testen: http://www.gmx.net/de/go/topmail
-
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