linux/pcifront: claim PCI resources also on rescan

linux/pcifront: claim PCI resources also on rescan

Condensed from the following two patches:

http://git.kernel.org/?p=3Dlinux/kernel/git/konrad/xen.git;a=3Dcommitdiff;h=
=3D621d869f36b215d63bb99e7ecd7a11f029821b85=20
xen-pcifront: Claim PCI resources before going live.

author  Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>=09
        Fri, 18 Jun 2010 19:31:47 +0000 (15:31 -0400)
committer       Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>=09
        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-0xfb8=
5ffff])

even thought the memory region had been reserved before.

Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
http://git.kernel.org/?p=3Dlinux/kernel/git/konrad/xen.git;a=3Dcommitdiff;h=
=3D4a65de894fc0af05397eedca180d0ea7d8c6caba=20
xen-pcifront: Don't race with udev when discovering new devices.

author  Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>=09
        Fri, 23 Jul 2010 14:35:57 +0000 (10:35 -0400)
committer       Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>=09
        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>