From: Greg KH <greg@kroah.com>
To: "Maciej W. Rozycki" <macro@mips.com>
Cc: linux-kernel@vger.kernel.org, Chris Dearman <chris@mips.com>,
"Maciej W. Rozycki" <macro@linux-mips.org>
Subject: Re: [PATCH] Don't touch BARs of host bridges
Date: Fri, 17 Dec 2004 13:46:46 -0800 [thread overview]
Message-ID: <20041217214646.GB22597@kroah.com> (raw)
In-Reply-To: <Pine.LNX.4.61.0412092349560.6535@perivale.mips.com>
On Fri, Dec 10, 2004 at 12:20:40AM +0000, Maciej W. Rozycki wrote:
> Hello,
>
> BARs of host bridges often have special meaning and AFAIK are best left
> to be setup by the firmware or system-specific startup code and kept
> intact by the generic resource handler. For example a couple of host
> bridges used for MIPS processors interpret BARs as target-mode decoders
> for accessing host memory by PCI masters (which is quite reasonable).
> For them it's desirable to keep their decoded address range overlapping
> with the host RAM for simplicity if nothing else (I can imagine running
> out of address space with lots of memory and 32-bit PCI with no DAC
> support in the participating devices).
>
> This is already the case with the i386 and ppc platform-specific PCI
> resource allocators. Please consider the following change for the generic
> allocator. Currently we have a pile of hacks implemented for host bridges
> to be left untouched and I'd be pleased to remove them.
I've applied this to my trees, and it will show up in the next -mm
release, and then on to Linus's tree after 2.6.10 is out.
Oh, and next time, I need a "Signed-off-by:" line as per
Documentation/SubmittingPatches.
thanks,
greg k-h
prev parent reply other threads:[~2004-12-17 21:47 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
2004-12-13 2:46 ` Maciej W. Rozycki
2004-12-17 21:46 ` Greg KH [this message]
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=20041217214646.GB22597@kroah.com \
--to=greg@kroah.com \
--cc=chris@mips.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.