From: Ingo Molnar <mingo@elte.hu>
To: "H. Peter Anvin" <hpa@zytor.com>
Cc: Bjorn Helgaas <bjorn.helgaas@hp.com>,
Yinghai Lu <yinghai@kernel.org>,
Jesse Barnes <jbarnes@virtuousgeek.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"linux-pci@vger.kernel.org" <linux-pci@vger.kernel.org>,
Linus Torvalds <torvalds@linux-foundation.org>,
Thomas Gleixner <tglx@linutronix.de>
Subject: Re: [PATCH] x86/pci: intel bus root res with IOH reading -v2
Date: Tue, 13 Oct 2009 09:03:11 +0200 [thread overview]
Message-ID: <20091013070311.GB31483@elte.hu> (raw)
In-Reply-To: <4AD3A460.6060505@zytor.com>
* H. Peter Anvin <hpa@zytor.com> wrote:
> On 10/12/2009 02:45 PM, Bjorn Helgaas wrote:
>
> > For the patch in question, we don't even have a root cause for the
> > bug (or at least, I couldn't decipher it from the changelog).
> > There's a reference to _CRS being wrong, but we don't currently use
> > _CRS for x86 host bridges.
> >
> > But in general, my objection is that even if BIOS provides perfectly
> > valid information about host bridge apertures, the the fact that
> > Linux ignores that information means we have to add this sort of
> > vendor- specific code every time we trip over something. And we're
> > tripping over things quite often.
> >
> > Windows consumes this _CRS information, so while I grant there are
> > certainly BIOS bugs there, I think most of the bugs are actually in
> > Linux.
>
> I think the right policy for most if not all things should be "use the
> BIOS information unless we know better."
My argument is that if we know how to access the hardware and know how
to interpret its state then that is _ALWAYS_ higher quality information
than anything the BIOS tells us.
Basically the BIOS is a second-level fall-back, and the less we have to
use this fall-back in Linux, the better. In many cases we have no other
info but BIOS info - that puts all our eggs into the BIOS basket and we
have to live with that.
And reducing that dependency on the BIOS is what Yinghai's patch is
doing in essence - it adds a higher-grade source of information: reading
the PCI config space directly.
( I make no argument about the specific correctness of the patch - i
just raised the principle and i think we should move in this direction
in general. )
Thanks,
Ingo
next prev parent reply other threads:[~2009-10-13 7:04 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-10-05 4:54 Yinghai Lu
2009-10-06 16:52 ` Jesse Barnes
2009-10-06 17:33 ` Bjorn Helgaas
2009-10-06 17:51 ` Yinghai Lu
2009-10-06 18:57 ` Bjorn Helgaas
2009-10-12 20:34 ` Ingo Molnar
2009-10-12 20:49 ` Jesse Barnes
[not found] ` <200910121545.47794.bjorn.helgaas@hp.com>
2009-10-12 21:49 ` H. Peter Anvin
2009-10-13 7:03 ` Ingo Molnar [this message]
2009-10-12 22:14 ` Bjorn Helgaas
2009-10-19 20:17 ` 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=20091013070311.GB31483@elte.hu \
--to=mingo@elte.hu \
--cc=bjorn.helgaas@hp.com \
--cc=hpa@zytor.com \
--cc=jbarnes@virtuousgeek.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=tglx@linutronix.de \
--cc=torvalds@linux-foundation.org \
--cc=yinghai@kernel.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
all inboxes | Powered by JetHome®