All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ingo Molnar <mingo@elte.hu>
To: Bjorn Helgaas <bjorn.helgaas@hp.com>
Cc: 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>,
	"H. Peter Anvin" <hpa@zytor.com>
Subject: Re: [PATCH] x86/pci: intel bus root res with IOH reading -v2
Date: Mon, 12 Oct 2009 22:34:53 +0200	[thread overview]
Message-ID: <20091012203453.GC7648@elte.hu> (raw)
In-Reply-To: <200910061257.54877.bjorn.helgaas@hp.com>


* Bjorn Helgaas <bjorn.helgaas@hp.com> wrote:

> On Tuesday 06 October 2009 11:51:22 am Yinghai Lu wrote:
> > Bjorn Helgaas wrote:
> > > On Sunday 04 October 2009 10:54:24 pm Yinghai Lu wrote:
> > >> for intel system with multi IOH. we could read peer root resource from PCI conf,
> > >> and don't trust _CRS again for root bus
> > > 
> > > Ugh.  Are we going to end up with amd_bus.c, intel_bus.c, nvidia_bus.c,
> > > broadcom_bus.c, serverworks_bus.c, etc.?
> > only needed when you have muti ...
> 
> I think that translates to "yes, we will need all those bits as soon 
> as those vendors support larger systems with multiple IOHs."  And I 
> think that's the wrong answer.

Why is having cleanly separated per vendor information/driver wrong? I 
think it's the right answer in most cases. _Especially_ when the other 
option is to 'rely on the firmware'.

> > again we should trust HW conf than BIOS.
> 
> Certainly there's a tradeoff between a generic driver that relies on 
> the BIOS, and a platform-specific driver that uses only the hardware. 
> The first leaves us vulnerable to BIOS bugs, but the second leads to a 
> plethora of drivers that require updates as hardware changes.

We do that quite well in Linux - it's one of our main strengths.

Why should we have to rely on correct firmware? Why is it wrong to know 
about the hw's structure, to query the hardware and ignore the firmware 
if the hardware state tells us otherwise?

	Ingo

  reply	other threads:[~2009-10-12 20:35 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-10-05  4:54 [PATCH] x86/pci: intel bus root res with IOH reading -v2 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 [this message]
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
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=20091012203453.GC7648@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 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.