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

[Bjorn Helgaas <bjorn.helgaas@hp.com>]

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