-------- Original-Nachricht -------- Datum: Fri, 30 Jun 2006 10:03:57 -0600 Von: Bjorn Helgaas <bjorn.helgaas@xxxxxx> An: Uwe Bugla <uwe.bugla@xxxxxx> 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@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
