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

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

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