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

On Wed, Oct 06, 2010 at 05:39:53PM -0600, Bjorn Helgaas wrote:
> On Wed, Oct 06, 2010 at 03:58:34PM -0700, Ram Pai wrote:
> >         PCI: override BIOS/firmware memory resource allocation
> > 		through command line parameters
> > 
> > 	Platforms that are unaware of  SRIOV  BARs  fail to allocate MMIO
> > 	resources  to SRIOV PCIe  devices. Hence  on  such  platforms the
> > 	OS fails to  enable  SRIOV.
> > 	Some  platforms  where  BIOS/uEFI resource   allocations  conflict
> > 	the conflicting devices are disabled.
> > 
> > 	Ideally we  would  want  the  OS  to detect and fix automatically
> > 	such problems and conflicts.  However previous  attempts to do so
> > 	have led to regression on legacy platforms.
> 
> I'm sorry to be a nay-sayer, but I think we just haven't tried hard
> enough.  Our ACPI/PCI/e820 resource management is not well integrated,
> and I suspect if we straightened that out, we could avoid some of the
> regressions we saw with previous attempts.

Can you be more specific as to what can be done to fix it automatically?

Neither accepting this approach nor telling what needs to be straightened out
to automatically fix all the systems out there, is just a deadend.

The choice is between
	(a) an automated patch with the risk of regressing some platforms.
	(b) an semi-automated patch that does not regress *any* platform,
		with the ability to fix platforms that are currently broken.
	(c) status quo, which means broken platforms continue to be so.

I thought the initial proposal was to use (b), with the long
term goal of fixing it automatically, assuming that it is even possible.

Let me know if that is *not* the goal and I will change directions.
RP

  reply	other threads:[~2010-10-07  0:30 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 [this message]
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
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=20101007003041.GF2945@ram-laptop \
    --to=linuxram@us.ibm.com \
    --cc=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=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.