From: "Jan Beulich" <JBeulich@novell.com>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: [PATCH] linux/pcifront: claim PCI resources also on rescan
Date: Mon, 04 Oct 2010 12:03:59 +0100 [thread overview]
Message-ID: <4CA9D0BF020000780001A5A0@vpn.id2.novell.com> (raw)
[-- Attachment #1: Type: text/plain, Size: 2386 bytes --]
Condensed from the following two patches:
http://git.kernel.org/?p=linux/kernel/git/konrad/xen.git;a=commitdiff;h=621d869f36b215d63bb99e7ecd7a11f029821b85
xen-pcifront: Claim PCI resources before going live.
author Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Fri, 18 Jun 2010 19:31:47 +0000 (15:31 -0400)
committer Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Fri, 18 Jun 2010 19:40:37 +0000 (15:40 -0400)
We were missing the important step of claiming (and setting the
parent of IO and MEM regions to 'PCI IO' and 'PCI mem' respectivly)
of the BARs. This meant that during hot inserts we would get:
igb 0000:01:00.1: device not available (can't reserve [mem 0xfb840000-0xfb85ffff])
even thought the memory region had been reserved before.
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
http://git.kernel.org/?p=linux/kernel/git/konrad/xen.git;a=commitdiff;h=4a65de894fc0af05397eedca180d0ea7d8c6caba
xen-pcifront: Don't race with udev when discovering new devices.
author Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Fri, 23 Jul 2010 14:35:57 +0000 (10:35 -0400)
committer Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Fri, 23 Jul 2010 15:15:56 +0000 (11:15 -0400)
We inadvertly would call 'pci_bus_add_device' right after discovering
the device, but before claiming the BARs. This ended up firing off
a uevent and udev loading the module and the modules failing to
request_region as they were not claimed. We fix this by holding off
going live by calling 'pci_bus_add_devices' at the end.
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Signed-off-by: Jan Beulich <jbeulich@novell.com>
Reported-by: Rafal Wojtczuk <rafal@invisiblethingslab.com>
--- a/drivers/xen/pcifront/pci_op.c
+++ b/drivers/xen/pcifront/pci_op.c
@@ -529,14 +529,18 @@ int __devinit pcifront_rescan_root(struc
}
d = pci_scan_single_device(b, devfn);
- if (d) {
+ if (d)
dev_info(&pdev->xdev->dev, "New device on "
"%04x:%02x:%02x.%02x found.\n", domain, bus,
PCI_SLOT(devfn), PCI_FUNC(devfn));
- pci_bus_add_device(d);
- }
}
+ /* Claim resources before going "live" with our devices */
+ pci_walk_bus(b, pcifront_claim_resource, pdev);
+
+ /* Create SysFS and notify udev of the devices. Aka: "going live" */
+ pci_bus_add_devices(b);
+
return 0;
}
[-- Attachment #2: xen-pcifront-rescan-claim.patch --]
[-- Type: text/plain, Size: 2435 bytes --]
Subject: pcifront: claim PCI resources also on rescan
Condensed from the following two patches:
http://git.kernel.org/?p=linux/kernel/git/konrad/xen.git;a=commitdiff;h=621d869f36b215d63bb99e7ecd7a11f029821b85
xen-pcifront: Claim PCI resources before going live.
author Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Fri, 18 Jun 2010 19:31:47 +0000 (15:31 -0400)
committer Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Fri, 18 Jun 2010 19:40:37 +0000 (15:40 -0400)
We were missing the important step of claiming (and setting the
parent of IO and MEM regions to 'PCI IO' and 'PCI mem' respectivly)
of the BARs. This meant that during hot inserts we would get:
igb 0000:01:00.1: device not available (can't reserve [mem 0xfb840000-0xfb85ffff])
even thought the memory region had been reserved before.
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
http://git.kernel.org/?p=linux/kernel/git/konrad/xen.git;a=commitdiff;h=4a65de894fc0af05397eedca180d0ea7d8c6caba
xen-pcifront: Don't race with udev when discovering new devices.
author Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Fri, 23 Jul 2010 14:35:57 +0000 (10:35 -0400)
committer Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Fri, 23 Jul 2010 15:15:56 +0000 (11:15 -0400)
We inadvertly would call 'pci_bus_add_device' right after discovering
the device, but before claiming the BARs. This ended up firing off
a uevent and udev loading the module and the modules failing to
request_region as they were not claimed. We fix this by holding off
going live by calling 'pci_bus_add_devices' at the end.
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Signed-off-by: Jan Beulich <jbeulich@novell.com>
Reported-by: Rafal Wojtczuk <rafal@invisiblethingslab.com>
--- a/drivers/xen/pcifront/pci_op.c
+++ b/drivers/xen/pcifront/pci_op.c
@@ -529,14 +529,18 @@ int __devinit pcifront_rescan_root(struc
}
d = pci_scan_single_device(b, devfn);
- if (d) {
+ if (d)
dev_info(&pdev->xdev->dev, "New device on "
"%04x:%02x:%02x.%02x found.\n", domain, bus,
PCI_SLOT(devfn), PCI_FUNC(devfn));
- pci_bus_add_device(d);
- }
}
+ /* Claim resources before going "live" with our devices */
+ pci_walk_bus(b, pcifront_claim_resource, pdev);
+
+ /* Create SysFS and notify udev of the devices. Aka: "going live" */
+ pci_bus_add_devices(b);
+
return 0;
}
[-- Attachment #3: Type: text/plain, Size: 138 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
reply other threads:[~2010-10-04 11:03 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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=4CA9D0BF020000780001A5A0@vpn.id2.novell.com \
--to=jbeulich@novell.com \
--cc=xen-devel@lists.xensource.com \
/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).