linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: James Bottomley <James.Bottomley@steeleye.com>
To: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: Linus Torvalds <torvalds@osdl.org>, Andrew Morton <akpm@osdl.org>,
	Linux Kernel <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] Intel Alder IOAPIC fix
Date: 17 Jan 2004 10:18:23 -0500	[thread overview]
Message-ID: <1074352704.2015.8.camel@mulgrave> (raw)
In-Reply-To: <m13cagbgrc.fsf@ebiederm.dsl.xmission.com>

On Fri, 2004-01-16 at 00:32, Eric W. Biederman wrote:
> Yes, this is the extreme case.  In normal cases I would just
> expect to push to one side and probably shrink it to 0.  I guess
> I have something against implying a hierarchal relationship that
> does not exist.

Well, it makes sense to me that the resource would be a child of the
reserved area, because the reserved area covers the APICs and this
rather annoying PCI device has one of the IO APICs tied to BAR0.

In this case, we have a PCI device claiming something we already
discovered and made use of long ago in bootup.

> Right.  To me it looks like separate cases.  What I keep envisioning
> scanning the PCI devices and then realizing they are behind
> a bridge.  Before I go to far I guess I should ask.
> 
> The splitting/pushing aside looks especially useful for those
> cases where you subdivide the resource again.
> 
> As for the bridge case I think that is something different.  

The pragmatist in me says we can handle them all as a single case. 
Simply put, it means insert_resource() says "I know this belongs in the
resource tree, just put it in where it should go, please".  As long as
we make sure we only use it for the exception cases, it should all work
fine.

All I really want is to get the alter 4 and 8 way boxes working again,
I'm happy to go with whatever people decide about resources.  What other
uses are there for the TENTATIVE regions?

James



  reply	other threads:[~2004-01-17 15:18 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-01-12  2:55 [PATCH] Intel Alder IOAPIC fix James Bottomley
2004-01-12 21:24 ` Linus Torvalds
2004-01-12 22:13   ` James Bottomley
2004-01-12 23:04   ` James Bottomley
2004-01-12 23:04     ` Linus Torvalds
2004-01-13  0:25       ` James Bottomley
2004-01-13  0:45       ` James Bottomley
2004-01-13  0:25         ` Linus Torvalds
2004-01-13 16:52           ` James Bottomley
2004-01-15  5:18             ` Eric W. Biederman
2004-01-15 16:58               ` James Bottomley
2004-01-15 19:26                 ` Eric W. Biederman
2004-01-15 19:54                   ` James Bottomley
2004-01-16  5:32                     ` Eric W. Biederman
2004-01-17 15:18                       ` James Bottomley [this message]
2004-01-17 19:43                         ` Eric W. Biederman

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=1074352704.2015.8.camel@mulgrave \
    --to=james.bottomley@steeleye.com \
    --cc=akpm@osdl.org \
    --cc=ebiederm@xmission.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=torvalds@osdl.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).