All of lore.kernel.org
 help / color / mirror / Atom feed
From: Bjorn Helgaas <bjorn.helgaas@hp.com>
To: Ram Pai <linuxram@us.ibm.com>
Cc: Jesse Barnes <jbarnes@virtuousgeek.org>,
	linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org,
	clemens@ladisch.de, Yinghai Lu <yinghai@kernel.org>,
	Linus Torvalds <torvalds@linux-foundation.org>
Subject: Re: [RFC v2 PATCH 1/1] PCI: override BIOS/firmware resource allocation
Date: Fri, 22 Oct 2010 15:49:21 -0600	[thread overview]
Message-ID: <201010221549.22124.bjorn.helgaas@hp.com> (raw)
In-Reply-To: <20101022185937.GF24820@ram-laptop>

On Friday, October 22, 2010 12:59:37 pm Ram Pai wrote:
> On Fri, Oct 22, 2010 at 11:55:18AM -0600, Bjorn Helgaas wrote:
> > If we assign resources to bridges with no devices behind them while
> > starving bridges that DO have devices behind them, I think that's a bug.
> > It'd be great if you could isolate and fix that before we complicate
> > things by throwing Yinghai's patch into the mix.
> 
> Yes. I sent out a patch an hour back with a fix for that.

Yeah, I saw that right after I hit "send" :-)

> > I think it'd interesting to have a debug parameter like "pci=assign-all"
> > that meant "ignore all BIOS PCI config and start from scratch."  I'm
> > sure we'd trip over lots of issues and it would be easier to resolve them
> > before trying to make things fancier.
> 
> The patch that I had sent 3-weeks back had that feature. It can be triggered
> by pci=override=always.
> 
> However, your arguement earlier was that it would make no difference because
> no one will enable that parameter by default. This means hardly anyone will
> report any bugs. 

I just meant as a development tool, maybe not even upstream, as a way
to exercise the Linux allocation code.  I don't have much confidence
in it yet.  We certainly don't want Linux to ignore the BIOS config in
general; we should just use it unless we can tell it's broken.

> Gating "Yinghai's patch or any other approach" on fixing all the bugs in the
> pci subsystem, implicitly means 'go away' ;). I hope you dont mean that.

Oh, no.

> I propose to bring Yinghai's patch, for that will enable us to expose bugs and
> at the same time it will enable SRIOV on *all* the platforms that don't have it.

Yes, we should consider Yinghai's patch again after all the known issues
with it are fixed.  I just don't know whether we're there yet.

Bjorn

  reply	other threads:[~2010-10-22 21:50 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-10-06 22:58 [RFC v2 PATCH 1/1] PCI: override BIOS/firmware resource allocation Ram Pai
2010-10-06 23:39 ` Bjorn Helgaas
2010-10-07  0:30   ` Ram Pai
2010-10-07  4:13     ` Bjorn Helgaas
2010-10-07 20:42       ` Ram Pai
2010-10-07 21:41         ` Bjorn Helgaas
2010-10-08 17:32           ` Ram Pai
2010-10-08 20:16             ` Bjorn Helgaas
2010-10-12  7:05               ` Ram Pai
2010-10-12 19:01                 ` Bjorn Helgaas
2010-10-18 20:10                   ` Jesse Barnes
2010-10-19 17:17                     ` Ram Pai
2010-10-19 18:24                       ` Jesse Barnes
2010-10-22  0:28                         ` Ram Pai
2010-10-22 17:55                           ` Bjorn Helgaas
2010-10-22 18:59                             ` Ram Pai
2010-10-22 21:49                               ` Bjorn Helgaas [this message]
2010-10-22 17:16                         ` [PATCH 1/1] PCI: ignore failure to preallocate minimal resources to hotplug bridges Ram Pai
2010-10-22 22:16                           ` Bjorn Helgaas
2011-01-07 22:32                           ` Jesse Barnes
2011-01-11 21:10                             ` Ram Pai
2011-01-14 18:19                               ` [PATCH 1/1] PCI: allocate essential resources before reserving hotplug resources Ram Pai
2011-01-18 20:52                                 ` Bjorn Helgaas
2011-01-18 21:42                                   ` Ram Pai
2011-01-18 22:11                                     ` Bjorn Helgaas
2011-01-19 19:58                                       ` [PATCH 1/1 v3] " Ram Pai
2011-01-20  1:00                                         ` [PATCH 1/1 v4] " Ram Pai
2011-01-21  1:22                                           ` Yinghai Lu
2011-01-21  7:17                                             ` Ram Pai
2011-01-18 21:30                                 ` [PATCH 1/1 Version 2.0] " Ram Pai
2011-01-18 21:46                                   ` Bjorn Helgaas
2011-01-18 22:03                                     ` Ram Pai

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=201010221549.22124.bjorn.helgaas@hp.com \
    --to=bjorn.helgaas@hp.com \
    --cc=clemens@ladisch.de \
    --cc=jbarnes@virtuousgeek.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=linuxram@us.ibm.com \
    --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.