Commit e76e5b2c authored by Linus Torvalds's avatar Linus Torvalds
Browse files

Merge branch 'linux-next' of git://git.kernel.org/pub/scm/linux/kernel/git/jbarnes/pci-2.6 

* 'linux-next' of git://git.kernel.org/pub/scm/linux/kernel/git/jbarnes/pci-2.6: (88 commits)
  PCI: fix HT MSI mapping fix
  PCI: don't enable too much HT MSI mapping
  x86/PCI: make pci=lastbus=255 work when acpi is on
  PCI: save and restore PCIe 2.0 registers
  PCI: update fakephp for bus_id removal
  PCI: fix kernel oops on bridge removal
  PCI: fix conflict between SR-IOV and config space sizing
  powerpc/PCI: include pci.h in powerpc MSI implementation
  PCI Hotplug: schedule fakephp for feature removal
  PCI Hotplug: rename legacy_fakephp to fakephp
  PCI Hotplug: restore fakephp interface with complete reimplementation
  PCI: Introduce /sys/bus/pci/devices/.../rescan
  PCI: Introduce /sys/bus/pci/devices/.../remove
  PCI: Introduce /sys/bus/pci/rescan
  PCI: Introduce pci_rescan_bus()
  PCI: do not enable bridges more than once
  PCI: do not initialize bridges more than once
  PCI: always scan child buses
  PCI: pci_scan_slot() returns newly found devices
  PCI: don't scan existing devices
  ...

Fix trivial append-only conflict in Documentation/feature-removal-schedule.txt
parents 32527bc0 eeafda70

Documentation/ABI/testing/sysfs-bus-pci

+70 −0
Original line number Diff line number Diff line
@@ -41,6 +41,49 @@ Description: 
		for the device and attempt to bind to it.  For example:

		# echo "8086 10f5" > /sys/bus/pci/drivers/foo/new_id



What:		/sys/bus/pci/drivers/.../remove_id

Date:		February 2009

Contact:	Chris Wright <chrisw@sous-sol.org>

Description:

		Writing a device ID to this file will remove an ID

		that was dynamically added via the new_id sysfs entry.

		The format for the device ID is:

		VVVV DDDD SVVV SDDD CCCC MMMM.	That is Vendor ID, Device

		ID, Subsystem Vendor ID, Subsystem Device ID, Class,

		and Class Mask.  The Vendor ID and Device ID fields are

		required, the rest are optional.  After successfully

		removing an ID, the driver will no longer support the

		device.  This is useful to ensure auto probing won't

		match the driver to the device.  For example:

		# echo "8086 10f5" > /sys/bus/pci/drivers/foo/remove_id



What:		/sys/bus/pci/rescan

Date:		January 2009

Contact:	Linux PCI developers <linux-pci@vger.kernel.org>

Description:

		Writing a non-zero value to this attribute will

		force a rescan of all PCI buses in the system, and

		re-discover previously removed devices.

		Depends on CONFIG_HOTPLUG.



What:		/sys/bus/pci/devices/.../remove

Date:		January 2009

Contact:	Linux PCI developers <linux-pci@vger.kernel.org>

Description:

		Writing a non-zero value to this attribute will

		hot-remove the PCI device and any of its children.

		Depends on CONFIG_HOTPLUG.



What:		/sys/bus/pci/devices/.../rescan

Date:		January 2009

Contact:	Linux PCI developers <linux-pci@vger.kernel.org>

Description:

		Writing a non-zero value to this attribute will

		force a rescan of the device's parent bus and all

		child buses, and re-discover devices removed earlier

		from this part of the device tree.

		Depends on CONFIG_HOTPLUG.



What:		/sys/bus/pci/devices/.../vpd

Date:		February 2008

Contact:	Ben Hutchings <bhutchings@solarflare.com>
@@ -52,3 +95,30 @@ Description: 
		that some devices may have malformatted data.  If the

		underlying VPD has a writable section then the

		corresponding section of this file will be writable.



What:		/sys/bus/pci/devices/.../virtfnN

Date:		March 2009

Contact:	Yu Zhao <yu.zhao@intel.com>

Description:

		This symbolic link appears when hardware supports the SR-IOV

		capability and the Physical Function driver has enabled it.

		The symbolic link points to the PCI device sysfs entry of the

		Virtual Function whose index is N (0...MaxVFs-1).



What:		/sys/bus/pci/devices/.../dep_link

Date:		March 2009

Contact:	Yu Zhao <yu.zhao@intel.com>

Description:

		This symbolic link appears when hardware supports the SR-IOV

		capability and the Physical Function driver has enabled it,

		and this device has vendor specific dependencies with others.

		The symbolic link points to the PCI device sysfs entry of

		Physical Function this device depends on.



What:		/sys/bus/pci/devices/.../physfn

Date:		March 2009

Contact:	Yu Zhao <yu.zhao@intel.com>

Description:

		This symbolic link appears when a device is a Virtual Function.

		The symbolic link points to the PCI device sysfs entry of the

		Physical Function this device associates with.

Documentation/DocBook/kernel-api.tmpl

+1 −0
Original line number Diff line number Diff line
@@ -199,6 +199,7 @@ X!Edrivers/pci/hotplug.c 
-->

!Edrivers/pci/probe.c

!Edrivers/pci/rom.c

!Edrivers/pci/iov.c

     </sect1>

     <sect1><title>PCI Hotplug Support Library</title>

!Edrivers/pci/hotplug/pci_hotplug_core.c

Documentation/PCI/MSI-HOWTO.txt

+332 −482

File changed.

Preview size limit exceeded, changes collapsed.

Documentation/PCI/pci-iov-howto.txt

0 → 100644
+99 −0
Original line number Diff line number Diff line 
		PCI Express I/O Virtualization Howto

		Copyright (C) 2009 Intel Corporation

		    Yu Zhao <yu.zhao@intel.com>





1. Overview



1.1 What is SR-IOV



Single Root I/O Virtualization (SR-IOV) is a PCI Express Extended

capability which makes one physical device appear as multiple virtual

devices. The physical device is referred to as Physical Function (PF)

while the virtual devices are referred to as Virtual Functions (VF).

Allocation of the VF can be dynamically controlled by the PF via

registers encapsulated in the capability. By default, this feature is

not enabled and the PF behaves as traditional PCIe device. Once it's

turned on, each VF's PCI configuration space can be accessed by its own

Bus, Device and Function Number (Routing ID). And each VF also has PCI

Memory Space, which is used to map its register set. VF device driver

operates on the register set so it can be functional and appear as a

real existing PCI device.



2. User Guide



2.1 How can I enable SR-IOV capability



The device driver (PF driver) will control the enabling and disabling

of the capability via API provided by SR-IOV core. If the hardware

has SR-IOV capability, loading its PF driver would enable it and all

VFs associated with the PF.



2.2 How can I use the Virtual Functions



The VF is treated as hot-plugged PCI devices in the kernel, so they

should be able to work in the same way as real PCI devices. The VF

requires device driver that is same as a normal PCI device's.



3. Developer Guide



3.1 SR-IOV API



To enable SR-IOV capability:

	int pci_enable_sriov(struct pci_dev *dev, int nr_virtfn);

	'nr_virtfn' is number of VFs to be enabled.



To disable SR-IOV capability:

	void pci_disable_sriov(struct pci_dev *dev);



To notify SR-IOV core of Virtual Function Migration:

	irqreturn_t pci_sriov_migration(struct pci_dev *dev);



3.2 Usage example



Following piece of code illustrates the usage of the SR-IOV API.



static int __devinit dev_probe(struct pci_dev *dev, const struct pci_device_id *id)

{

	pci_enable_sriov(dev, NR_VIRTFN);



	...



	return 0;

}



static void __devexit dev_remove(struct pci_dev *dev)

{

	pci_disable_sriov(dev);



	...

}



static int dev_suspend(struct pci_dev *dev, pm_message_t state)

{

	...



	return 0;

}



static int dev_resume(struct pci_dev *dev)

{

	...



	return 0;

}



static void dev_shutdown(struct pci_dev *dev)

{

	...

}



static struct pci_driver dev_driver = {

	.name =		"SR-IOV Physical Function driver",

	.id_table =	dev_id_table,

	.probe =	dev_probe,

	.remove =	__devexit_p(dev_remove),

	.suspend =	dev_suspend,

	.resume =	dev_resume,

	.shutdown =	dev_shutdown,

};

Documentation/feature-removal-schedule.txt

+32 −0
Original line number Diff line number Diff line
@@ -392,3 +392,35 @@ Why: The defines and typedefs (hw_interrupt_type, no_irq_type, irq_desc_t) 
	have been kept around for migration reasons. After more than two years

	it's time to remove them finally

Who:	Thomas Gleixner <tglx@linutronix.de>



---------------------------



What:	fakephp and associated sysfs files in /sys/bus/pci/slots/

When:	2011

Why:	In 2.6.27, the semantics of /sys/bus/pci/slots was redefined to

	represent a machine's physical PCI slots. The change in semantics

	had userspace implications, as the hotplug core no longer allowed

	drivers to create multiple sysfs files per physical slot (required

	for multi-function devices, e.g.). fakephp was seen as a developer's

	tool only, and its interface changed. Too late, we learned that

	there were some users of the fakephp interface.



	In 2.6.30, the original fakephp interface was restored. At the same

	time, the PCI core gained the ability that fakephp provided, namely

	function-level hot-remove and hot-add.



	Since the PCI core now provides the same functionality, exposed in:



		/sys/bus/pci/rescan

		/sys/bus/pci/devices/.../remove

		/sys/bus/pci/devices/.../rescan



	there is no functional reason to maintain fakephp as well.



	We will keep the existing module so that 'modprobe fakephp' will

	present the old /sys/bus/pci/slots/... interface for compatibility,

	but users are urged to migrate their applications to the API above.



	After a reasonable transition period, we will remove the legacy

	fakephp interface.

Who:	Alex Chiang <achiang@hp.com>

CRA Git | Maintained and supported by SUSTech CRA and CCSE