public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Andi Kleen <ak@suse.de>
To: Greg KH <gregkh@suse.de>
Cc: Linus Torvalds <torvalds@osdl.org>, Andrew Morton <akpm@osdl.org>,
	linux-kernel@vger.kernel.org, linux-pci@atrey.karlin.mff.cuni.cz
Subject: Re: [patch 2/4] i386/x86-64: Implement fallback for PCI mmconfig to type1
Date: 12 Dec 2005 22:02:19 -0700	[thread overview]
Message-ID: <p734q5da8tg.fsf@verdi.suse.de> (raw)
In-Reply-To: <20051212211553.GA29112@suse.de>


Sorry Greg, Linus,

I also submitted the two PCI patches on my own with the x86-64
patchkit, hopefully the duplication doesn't cause too much trouble.

Greg KH <gregkh@suse.de> writes:
> 
> From what I can tell, it's too late in the callstack for us to change
> the read ops for this device to be the other one.  The problem is (and
> Andi can correct me if I'm wrong), some boxes basically have incomplete
> MCFG acpi tables (the tables do not describe all PCI busses that are
> present in the box).  But we don't realize this until we are about to do
> the read function.

It can happen with perfectly legal MCFG tables. If a bus is not listed
in MCFG then we must fallback to type1. This happens on AMD K8 systems
because the busses in the builtin northbridge don't support mmconfig,
only busses on external bridges do. In theory it could happen on
other systems too (although external northbridges typically support
mmconfig for everything if they do at all) 

In addition we have some boxes with broken MCFG tables who don't get
the tables right, this is what the next patch was trying to fix.

> I remember I looked into trying to set this up at probe/init time, and
> it was almost impossible to do so, due to the structure of the code.

Yes, I also didn't see an easy way to do it, although it would be probably DTRT. 

-Andi

  reply	other threads:[~2005-12-13  0:30 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20051212192030.873030000@press.kroah.org>
2005-12-12 20:00 ` [patch 0/4] Small fixes for 2.6.15-rc5 Greg Kroah-Hartman
2005-12-12 20:01   ` [patch 1/4] i2c: Fix i2c-mv64xxx compilation error Greg Kroah-Hartman
2005-12-12 20:01   ` [patch 2/4] i386/x86-64: Implement fallback for PCI mmconfig to type1 Greg Kroah-Hartman
2005-12-12 20:26     ` Matthew Wilcox
2005-12-12 21:15       ` Greg KH
2005-12-13  5:02         ` Andi Kleen [this message]
2005-12-12 20:01   ` [patch 3/4] x86_64/i386: Correct for broken MCFG tables on K8 systems Greg Kroah-Hartman
2005-12-12 20:01   ` [patch 4/4] UHCI: add missing memory barriers Greg Kroah-Hartman
2005-12-13  0:27     ` Jeff Garzik
2005-12-13  3:03       ` Greg KH
2005-12-13  3:32       ` Alan Stern

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=p734q5da8tg.fsf@verdi.suse.de \
    --to=ak@suse.de \
    --cc=akpm@osdl.org \
    --cc=gregkh@suse.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@atrey.karlin.mff.cuni.cz \
    --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