On Tuesday, September 02, 2008 12:41 AM, Alex Chiang wrote: >* Zhao, Yu <yu.zhao@xxxxxxxxx>: >> Support SR-IOV capability. By default, this feature is not enabled and the >SR-IOV device behaves as traditional PCI device. After it's enabled, each >Virtual Function's PCI configuration space can be accessed using its own Bus, >Device and Function Number (Routing ID). Each Virtual Function also has PCI >Memory Space, which is used to map its own register set. >> >> Signed-off-by: Yu Zhao <yu.zhao@xxxxxxxxx> >> Signed-off-by: Eddie Dong <eddie.dong@xxxxxxxxx> >> >> --- >> drivers/pci/Kconfig | 10 + >> drivers/pci/Makefile | 2 + >> drivers/pci/iov.c | 555 >++++++++++++++++++++++++++++++++++++++++++++++ >> drivers/pci/pci.c | 14 +- >> drivers/pci/pci.h | 44 ++++ >> drivers/pci/probe.c | 5 + >> include/linux/pci.h | 28 +++ >> include/linux/pci_regs.h | 20 ++ >> 8 files changed, 677 insertions(+), 1 deletions(-) >> create mode 100644 drivers/pci/iov.c >> > >So, what happens if another hotplug driver is already loaded? > >I don't know the SR-IOV spec well enough to know if you are >allowed to have SR-IOV + some other form of hotplug, like ACPI or >native PCIe. > >Today, pci_hp_register will return -EBUSY. > >If SR-IOV really doesn't have anything to do with hotplug, then >it may be a candidate for directly calling pci_create_slot(). In >that case, 'param' should not be a property of a hotplug slot, >but of a generic PCI slot. That's correct, SR-IOV really doesn't have anything to do with hotplug. I was just reusing hotplug sysfs as the control interface. Will remove this in next work, and create SR-IOV own sysfs entries under /sys/bus/pci/devices/.../iov/... Thanks. > >Thanks. > >/ac -- To unsubscribe from this list: send the line "unsubscribe linux-pci" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
