From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: "Maciej W. Rozycki" <macro@linux-mips.org>
Cc: "Maciej W. Rozycki" <macro@mips.com>, Greg KH <greg@kroah.com>,
Linux Kernel list <linux-kernel@vger.kernel.org>,
Chris Dearman <chris@mips.com>
Subject: Re: [PATCH] Don't touch BARs of host bridges
Date: Sat, 11 Dec 2004 08:25:04 +1100 [thread overview]
Message-ID: <1102713904.5237.3.camel@gaston> (raw)
In-Reply-To: <Pine.LNX.4.58L.0412100448490.30913@blysk.ds.pg.gda.pl>
On Fri, 2004-12-10 at 13:11 +0000, Maciej W. Rozycki wrote:
> Well, some of these bridges may be used for peripheral devices (option
> cards) built around a CPU, typically after reprogramming the class code to
> something corresponding to their actual function. Why should the address
> decoder circuitry suddenly change in this case?
To stay in the PCI spec ? :) They would need at least a way to "lock"
the BARs.
> Also even in the "host mode" another device may wish to examine what
> resources have been reserved by the host bridge (unlikely, I admit, but
> in principle why not?).
Very unlikely.
> > was well :) So I agree, that would be useful to skip them. I'm not sure
> > about PCI_CLASS_NOT_DEFINED tho ...
>
> These are pre-2.0 PCI devices -- from before the detailed classification
> was agreed upon. AFAIK, just a couple of them exist -- I can name:
> Intel's 82424 and 82425 families of i486 host bridges, their 82375 family
> of PCI-EISA bridges and their 82378/9 family of PCI-ISA bridges (also used
> in a few DEC Alpha systems). There are probably a handful of other chips,
> all of them about ten years old. Our i386 and ppc resource managers skip
> over them as well and I suppose this is a safe default. If any of them
> needs BAR setup (none of these Intel ones), it can be added explicitly by
> means of its vendor:device ID.
Ok.
Ben.
next prev parent reply other threads:[~2004-12-10 21:27 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-12-10 0:20 [PATCH] Don't touch BARs of host bridges Maciej W. Rozycki
2004-12-10 4:46 ` Benjamin Herrenschmidt
2004-12-10 13:11 ` Maciej W. Rozycki
2004-12-10 21:25 ` Benjamin Herrenschmidt [this message]
2004-12-13 2:46 ` Maciej W. Rozycki
2004-12-17 21:46 ` Greg KH
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=1102713904.5237.3.camel@gaston \
--to=benh@kernel.crashing.org \
--cc=chris@mips.com \
--cc=greg@kroah.com \
--cc=linux-kernel@vger.kernel.org \
--cc=macro@linux-mips.org \
--cc=macro@mips.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.