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

Uwe Bugla
2006-07-03T08:19:08Z

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