From: "H. Peter Anvin" <hpa@zytor.com>
To: Bjorn Helgaas <bjorn.helgaas@hp.com>
Cc: Yinghai Lu <yinghai.lu@oracle.com>,
Jesse Barnes <jbarnes@virtuousgeek.org>,
Thomas Gleixner <tglx@linutronix.de>, Ingo Molnar <mingo@elte.hu>,
Graham Ramsey <ramsey.graham@ntlworld.com>,
linux-kernel@vger.kernel.org, linux-pci@vger.kernel.org,
Robert Richter <robert.richter@amd.com>,
Harald Welte <HaraldWelte@viatech.com>,
Joseph Chan <JosephChan@via.com.tw>, Jiri Slaby <jslaby@suse.cz>,
Hidetoshi Seto <seto.hidetoshi@jp.fujitsu.com>,
Andrew Morton <akpm@linux-foundation.org>,
Dominik Brodowski <linux@dominikbrodowski.net>,
Myron Stowe <myron.stowe@hp.com>
Subject: Re: [PATCH -v2] x86, pci: Handle fallout pci devices with peer root bus
Date: Mon, 14 Jun 2010 18:56:17 -0700 [thread overview]
Message-ID: <4C16DDC1.30006@zytor.com> (raw)
In-Reply-To: <201006141949.51674.bjorn.helgaas@hp.com>
On 06/14/2010 06:49 PM, Bjorn Helgaas wrote:
>>
>> Invisible PCI bridges have been known to occur in pure PCI space, too.
>
> Are you talking about PCI host bridges that don't appear in PCI config
> space? I suppose those could be described as "invisible," but since
> host bridges aren't architected and their primary interface isn't PCI,
> it seems only natural that we'd discover them by a non-PCI mechanism.
> They're invisible in PCI terms, but obviously perfectly discoverable
> and configurable via ACPI.
I mean invisible PCI-PCI bridges. Yes, they exist.
> If you ask me, it's weird that most x86 chipsets put PCI host bridge
> configuration in PCI config space -- it may be convenient in some ways,
> but still architecturally strange.
It is only strange because they are non-bridge devices. PCI-Express
fixes that to some degree with the whole "root complex" notion, but
really a PCI host bridge should have been a bridge device from the start.
> I suppose one could argue that there's a non-standard P2P bridge
> from bus 00 to bus 80, but I can't imagine anybody doing that.
Ah, ye of little imagination.
> An OS would have to have vendor-specific code just to do PCI
> resource management, and that really misses the point of PCI.
This really misses the point of HT...
> It seems more likely to me that one of the VIA host bridges leads
> to bus 80. PCI host bridges are not architected, so if this bridge
> lives on HT chain 00, and we can think of HT as "not quite PCI,"
> then it seems natural that the host bridge would be VIA-specific,
> just like it was in pre-HT days.
I think the best word for it is "incompetent braindamage", but that's
just me...
-hpa
--
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel. I don't speak on their behalf.
next prev parent reply other threads:[~2010-06-15 1:57 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-05-19 15:13 x86/pci Oops with CONFIG_SND_HDA_INTEL Graham Ramsey
2010-05-19 16:44 ` Bjorn Helgaas
2010-05-19 17:16 ` Graham Ramsey
2010-05-19 18:01 ` Yinghai
2010-05-19 22:47 ` Graham Ramsey
2010-05-20 0:03 ` Yinghai
2010-05-20 0:22 ` Jesse Barnes
2010-05-20 0:36 ` Yinghai
2010-05-20 17:08 ` [Bug 16007] " Bjorn Helgaas
2010-06-02 16:58 ` Bjorn Helgaas
2010-06-11 21:49 ` Bjorn Helgaas
2010-06-11 22:08 ` Yinghai Lu
2010-06-11 23:06 ` Yinghai Lu
2010-06-14 14:18 ` Bjorn Helgaas
2010-06-14 17:47 ` [PATCH -v2] x86, pci: Handle fallout pci devices with peer root bus Yinghai Lu
2010-06-14 18:14 ` Jesse Barnes
2010-06-14 18:22 ` Yinghai Lu
2010-06-14 18:34 ` Bjorn Helgaas
2010-06-14 18:39 ` H. Peter Anvin
2010-06-14 18:55 ` Yinghai Lu
2010-06-14 20:00 ` Bjorn Helgaas
2010-06-14 20:08 ` H. Peter Anvin
2010-06-14 20:20 ` Bjorn Helgaas
2010-06-14 21:10 ` H. Peter Anvin
2010-06-15 1:49 ` Bjorn Helgaas
2010-06-15 1:56 ` H. Peter Anvin [this message]
2010-06-15 15:30 ` Bjorn Helgaas
2010-06-14 19:43 ` Bjorn Helgaas
2010-06-21 17:28 ` [Bug 16007] x86/pci Oops with CONFIG_SND_HDA_INTEL Bjorn Helgaas
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4C16DDC1.30006@zytor.com \
--to=hpa@zytor.com \
--cc=HaraldWelte@viatech.com \
--cc=JosephChan@via.com.tw \
--cc=akpm@linux-foundation.org \
--cc=bjorn.helgaas@hp.com \
--cc=jbarnes@virtuousgeek.org \
--cc=jslaby@suse.cz \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=linux@dominikbrodowski.net \
--cc=mingo@elte.hu \
--cc=myron.stowe@hp.com \
--cc=ramsey.graham@ntlworld.com \
--cc=robert.richter@amd.com \
--cc=seto.hidetoshi@jp.fujitsu.com \
--cc=tglx@linutronix.de \
--cc=yinghai.lu@oracle.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.