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

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

[Li, Shaohua]

>-----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

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

[Uwe Bugla]

-------- 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

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

[Shaohua Li]

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@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??
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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Uwe Bugla]

-------- Original-Nachricht --------
Datum: Fri, 30 Jun 2006 17:08:35 +0800
Von: Shaohua Li <shaohua.li@intel.com>
An: Uwe Bugla <uwe.bugla@gmx.de>
Betreff: Re: RE: Re: [patch 11/18] pnpacpi: reject ACPI_PRODUCER resources

> 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@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??
> I gave up, and didn't want to argue this issue any more
Hi Shaohua,
Sigh!!
This is no behaviour to bring anything forward. Guess we are missing more material, more information on specific platforms not conforming with that ACPI-PRODUCER rejectment. In any other case there won´t be any development forwards. Your kind of argumentation is more than (well, I am missing the right adjective for what I feel).
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

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

[Bjorn Helgaas]

On Friday 30 June 2006 03:04, Uwe Bugla wrote:
> 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."

A PCI root bridge is a device that sits between the processor and
a PCI bus.  On the upstream side (closer to the processor), it has
some platform-specific interface.  The downstream side is a standard
PCI bus.

Most PNP devices have some registers that control them.  For example,
a UART has a receive buffer, a transmit buffer, an interrupt enable
register, etc.  These appear at specific I/O port or MMIO addresses.
Those addresses are the resources consumed by the UART.  If you access
those resources, the UART responds by doing something.

Bridges are different.  They also consume I/O port and/or MMIO address
space.  But some of that address space is passed through to the other
side of the bridge, to the devices on the downstream bus.  In ACPI,
the resources that are passed to the downstream side are "consumed"
by the bridge and also "produced" on the downstream side.

The UART has no downstream side.  It "consumes" resources but
doesn't produce any.  (It does produce RS-232 signals on the
other side, but that's a completely different protocol and outside
the scope of ACPI.)

> 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.

My opinion is that we must change PNPACPI to either understand or
ignore the producer resources.  Matthieu posted a patch to ignore
them.  If we don't do this, we will have the maintenance burden of
updating a blacklist whenever anybody invents a new device with
producer resources.

We could blacklist PNP0A03 in addition to changing PNPACPI.  For the
specific bug you tripped over, there's no reason to do both, but I
think Shaohua is worried about other problems.  For example, if the
BIOS reported that the PNP0A03 device consumed I/O port 0x3f8, which
is really consumed by the COM1 UART, that conflict might prevent the
serial driver from using the UART.

Or, somebody could make a PNP driver that claimed PNP0A03 PCI root
bridges, which would conflict with the existing ACPI driver that
claims PNP0A03 devices.  Blacklisting PNP0A03 in PNPACPI would prevent
a PNP driver from claiming it.

Bjorn

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

[Uwe Bugla]

-------- Original-Nachricht --------
Datum: Fri, 30 Jun 2006 10:03:57 -0600
Von: Bjorn Helgaas <bjorn.helgaas@hp.com>
An: Uwe Bugla <uwe.bugla@gmx.de>
Betreff: Re: [patch 11/18] pnpacpi: reject ACPI_PRODUCER resources

> On Friday 30 June 2006 03:04, Uwe Bugla wrote:
> > 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."
> 
> A PCI root bridge is a device that sits between the processor and
> a PCI bus.  On the upstream side (closer to the processor), it has
> some platform-specific interface.  The downstream side is a standard
> PCI bus.
> 
> Most PNP devices have some registers that control them.  For example,
> a UART has a receive buffer, a transmit buffer, an interrupt enable
> register, etc.  These appear at specific I/O port or MMIO addresses.
> Those addresses are the resources consumed by the UART.  If you access
> those resources, the UART responds by doing something.
> 
> Bridges are different.  They also consume I/O port and/or MMIO address
> space.  But some of that address space is passed through to the other
> side of the bridge, to the devices on the downstream bus.  In ACPI,
> the resources that are passed to the downstream side are "consumed"
> by the bridge and also "produced" on the downstream side.
> 
> The UART has no downstream side.  It "consumes" resources but
> doesn't produce any.  (It does produce RS-232 signals on the
> other side, but that's a completely different protocol and outside
> the scope of ACPI.)
> 
> > 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.
> 
> My opinion is that we must change PNPACPI to either understand or
> ignore the producer resources.  Matthieu posted a patch to ignore
> them.  If we don't do this, we will have the maintenance burden of
> updating a blacklist whenever anybody invents a new device with
> producer resources.
> 
> We could blacklist PNP0A03 in addition to changing PNPACPI.  For the
> specific bug you tripped over, there's no reason to do both, but I
> think Shaohua is worried about other problems.  For example, if the
> BIOS reported that the PNP0A03 device consumed I/O port 0x3f8, which
> is really consumed by the COM1 UART, that conflict might prevent the
> serial driver from using the UART.
> 
> Or, somebody could make a PNP driver that claimed PNP0A03 PCI root
> bridges, which would conflict with the existing ACPI driver that
> claims PNP0A03 devices.  Blacklisting PNP0A03 in PNPACPI would prevent
> a PNP driver from claiming it.
> 
> Bjorn

Hi Bjorn,
lots of thanks for your explanations.
What is the path (or strategy) for a PNPACPI concept that handles all devices in a specific box without any IO or interrupt conflicts?
Is BIOS flashing a necessary part of this strategy?

Thanks
Uwe

-- 


Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen!
Ideal für Modem und ISDN: http://www.gmx.net/de/go/smartsurfer
-
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