linux-pci.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Nishanth Aravamudan <nacc@us.ibm.com>
To: Don Dutile <ddutile@redhat.com>
Cc: Ram Pai <linuxram@us.ibm.com>, Yinghai Lu <yinghai@kernel.org>,
	Jesse Barnes <jbarnes@virtuousgeek.org>,
	linux-pci@vger.kernel.org,
	Benjamin Herrenschmidt <benh@kernel.crashing.org>,
	Bjorn Helgaas <bhelgaas@google.com>,
	prarit@redhat.com, brking@linux.vnet.ibm.com
Subject: Re: [RFC PATCH 1/1]PCI: defer enablement of SRIOV BARS
Date: Wed, 7 Dec 2011 12:35:17 -0800	[thread overview]
Message-ID: <20111207203517.GB6431@us.ibm.com> (raw)
In-Reply-To: <4EDFCB4A.60106@redhat.com>

On 07.12.2011 [15:23:38 -0500], Don Dutile wrote:
> On 12/07/2011 04:25 AM, Ram Pai wrote:
> >On Wed, Dec 07, 2011 at 12:22:47AM -0800, Yinghai Lu wrote:
> >>On Mon, Dec 5, 2011 at 10:32 AM, Jesse Barnes<jbarnes@virtuousgeek.org>  wrote:
> >>>On Sun, 6 Nov 2011 10:33:10 +0800
> >>>Ram Pai<linuxram@us.ibm.com>  wrote:
> >>>
> >>>>
> >>>>   NOTE: Note, there is subtle change in the pci_enable_device() API.
> >>>>   Any driver that depends on SRIOV BARS to be enabled in pci_enable_device()
> >>>>   can fail.
> >>>>
> >>>>---
> >>>
> >>>Applied to my for-linus branch, thanks.
> >>>
> >>
> >>please don't push to linus now.
> >>
> >>this one causes regression.
> >>
> >>please check attached patch.
> >>
> >>Thanks
> >>
> >>Yinghai
> >
> >>[PATCH] pci: Fix hotplug of Express Module with pci bridges
> >>
> >>Found hotplug of one setup does not work with recent change in pci tree.
> >>
> >>After checking the bridge conf setup, found bridges get assigned, but not get enabled.
> >>
> >>Finally found following commit, simplely ignore bridge resource when enabling pci device.
> >>
> >>| commit bbef98ab0f019f1b0c25c1acdf1683c68933d41b
> >>| Author: Ram Pai<linuxram@us.ibm.com>
> >>| Date:   Sun Nov 6 10:33:10 2011 +0800
> >>|
> >>|    PCI: defer enablement of SRIOV BARS
> >>|...
> >>|    NOTE: Note, there is subtle change in the pci_enable_device() API.  Any
> >>|    driver that depends on SRIOV BARS to be enabled in pci_enable_device()
> >>|    can fail.
> >>
> >>Put back bridge resource and ROM resource checking to fix the problem.
> >>
> >>That should fix regression like BIOS does not assign correct resource to bridge.
> >>
> >>Signed-off-by: Yinghai Lu<yinghai@kernel.org>
> >>
> >>---
> >>  drivers/pci/pci.c |    6 +++++-
> >>  1 file changed, 5 insertions(+), 1 deletion(-)
> >>
> >>Index: linux-2.6/drivers/pci/pci.c
> >>===================================================================
> >>--- linux-2.6.orig/drivers/pci/pci.c
> >>+++ linux-2.6/drivers/pci/pci.c
> >>@@ -1139,7 +1139,11 @@ static int __pci_enable_device_flags(str
> >>  	if (atomic_add_return(1,&dev->enable_cnt)>  1)
> >>  		return 0;		/* already enabled */
> >>
> >>-	for (i = 0; i<  PCI_ROM_RESOURCE; i++)
> >>+	/* only skip sriov related */
> >>+	for (i = 0; i<= PCI_ROM_RESOURCE; i++)
> >>+		if (dev->resource[i].flags&  flags)
> >>+			bars |= (1<<  i);
> >>+	for (i = PCI_BRIDGE_RESOURCES; i<  DEVICE_COUNT_RESOURCE; i++)
> >>  		if (dev->resource[i].flags&  flags)
> >>  			bars |= (1<<  i);
> >>
> >
> >Oops. My patch inadvertently dropped ROM and BRIDGE resources.
> >
> >This patch is right. However would it help if we did something like this
> >to avoid some code duplication?
> >
> >	for (i = 0; i<  DEVICE_COUNT_RESOURCE;
> >		i == PCI_ROM_RESOURCE ? PCI_BRIDGE_RESOURCES: i++)
> >		if (dev->resource[i].flags&  flags)
> >			bars |= (1<<  i);
> >
> 
> why not something more explicit like:
> 
> 	for (i = 0; i < DEVICE_COUNT_RESOURCE; i++) {
> 		if ((i >=  PCI_IOV_RESOURCES) && (i <= PCI_IOV_RESOURCE_END))
> 			continue; /* skip sriov related resources */
>                 if (dev->resource[i].flags & flags)
>                         bars |= (1 << i);
> 	}

I agree with the more explicit approach, self-commenting and easier to
read. Although, you may want to add a comment as to *why* we're skipping
IOV BARs here.

-Nish

-- 
Nishanth Aravamudan <nacc@us.ibm.com>
IBM Linux Technology Center


  reply	other threads:[~2011-12-07 20:35 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20111006210320.GA14959@us.ibm.com>
     [not found] ` <CAErSpo7b_6_AaZXW9XBx5p3-0PZJk-1jeCork__KePdzCS89OA@mail.gmail.com>
     [not found]   ` <1317970100.29415.305.camel@pasglop>
     [not found]     ` <CAErSpo58okGsDW4dOK4i0g_RUejkuQa=iw2uQ5HAJJZCwFtsbw@mail.gmail.com>
     [not found]       ` <20111007232516.GF2980@ram-ThinkPad-T61>
     [not found]         ` <1318057168.29415.333.camel@pasglop>
     [not found]           ` <20111008075353.GK2980@ram-ThinkPad-T61>
     [not found]             ` <1318060793.29415.347.camel@pasglop>
     [not found]               ` <20111102140325.004b9dad@jbarnes-desktop>
     [not found]                 ` <20111103013014.GB393@ram-ThinkPad-T61>
     [not found]                   ` <20111106023310.GA2383@ram-ThinkPad-T61>
2011-11-11 18:01                     ` [RFC PATCH 1/1]PCI: defer enablement of SRIOV BARS Jesse Barnes
2011-11-14  4:33                       ` Ram Pai
2011-11-14  4:56                         ` Michael Wang
2011-12-05 18:32                     ` Jesse Barnes
2011-12-07  8:22                       ` Yinghai Lu
2011-12-07  9:25                         ` Ram Pai
2011-12-07 19:33                           ` Yinghai Lu
2011-12-07 20:23                           ` Don Dutile
2011-12-07 20:35                             ` Nishanth Aravamudan [this message]
2011-12-07 22:34                               ` Don Dutile
2011-12-07 23:11                             ` Yinghai Lu
2011-12-08  2:50                               ` Ram Pai
2011-12-08 13:53                                 ` Jesse Barnes
2011-12-08 16:59                                   ` Yinghai Lu
2011-12-09 10:04                                   ` [PATCH 1/1 v2]PCI: " Ram Pai
2011-12-08 16:22                                 ` [RFC PATCH 1/1]PCI: " Don Dutile
     [not found]                   ` <20111106023357.GB2383@ram-ThinkPad-T61>
2011-12-05 18:17                     ` [RFC PATCH 1/1] PCI:delay configuration of SRIOV capability Jesse Barnes
2011-12-05 21:25                       ` Don Dutile
2011-12-06  7:51                         ` Ram Pai
2011-12-06  9:14                           ` Don Dutile
2011-12-05 21:37                     ` Jesse Barnes

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=20111207203517.GB6431@us.ibm.com \
    --to=nacc@us.ibm.com \
    --cc=benh@kernel.crashing.org \
    --cc=bhelgaas@google.com \
    --cc=brking@linux.vnet.ibm.com \
    --cc=ddutile@redhat.com \
    --cc=jbarnes@virtuousgeek.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=linuxram@us.ibm.com \
    --cc=prarit@redhat.com \
    --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;
as well as URLs for NNTP newsgroup(s).