linux.git/drivers/pci, branch v2.6.31

PCI SR-IOV: correct broken resource alignment calculations

2009-08-30T15:37:25+00:00

An SR-IOV capable device includes an SR-IOV PCIe capability which
describes the Virtual Function (VF) BAR requirements.  A typical SR-IOV
device can support multiple VFs whose BARs must be in a contiguous region,
effectively an array of VF BARs.  The BAR reports the size requirement
for a single VF.  We calculate the full range needed by simply multiplying
the VF BAR size with the number of possible VFs and create a resource
spanning the full range.

This all seems sane enough except it artificially inflates the alignment
requirement for the VF BAR.  The VF BAR need only be aligned to the size
of a single BAR not the contiguous range of VF BARs.  This can cause us
to fail to allocate resources for the BAR despite the fact that we
actually have enough space.

This patch adds a thin PCI specific layer over the generic
resource_alignment() function which is aware of the special nature of
VF BARs and does sorting and allocation based on the smaller alignment
requirement.

I recognize that while resource_alignment is generic, it's basically a
PCI helper.  An alternative to this patch is to add PCI VF BAR specific
information to struct resource.  I opted for the extra layer rather than
adding such PCI specific information to struct resource.  This does
have the slight downside that we don't cache the BAR size and re-read
for each alignment query (happens a small handful of times during boot
for each VF BAR).

Signed-off-by: Chris Wright 
Cc: Ivan Kokshaysky 
Cc: Linus Torvalds 
Cc: Matthew Wilcox 
Cc: Yu Zhao 
Cc: stable@kernel.org
Signed-off-by: Jesse Barnes

PCI: check saved state before restore

2009-08-20T16:08:45+00:00

Without the check, the config space may be filled with zeros. Though
the driver should try to avoid call restoring before saving, but the
pci layer also should check this.

Also removes the existing check in pci_restore_standard_config, since
it's superfluous with the new check in restore_state.

Acked-by: Rafael J. Wysocki 
Signed-off-by: Alek Du 
Signed-off-by: Jesse Barnes

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

2009-08-10T18:00:37+00:00

* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jbarnes/pci-2.6:
  PCI hotplug: SGI hotplug: do not use hotplug_slot_attr
  PCI hotplug: SGI hotplug: fix build failure

PCI hotplug: SGI hotplug: do not use hotplug_slot_attr

2009-08-07T17:36:27+00:00

By the pci slot changes, callbacks of attributes under slot directory
(/sys/bus/pci/slots) had been changed to get the pointer to struct
pci_slot instead of struct hotplug_slot. So the path_show() that
assumes the parameter is a pointer to struct hotplug_slot seems
broken.

Tested-by: Mike Habeck 
Signed-off-by: Kenji Kaneshige 
Signed-off-by: Jesse Barnes

PCI hotplug: SGI hotplug: fix build failure

2009-08-07T17:36:26+00:00

The commit bd3d99c17039fd05a29587db3f4a180c48da115a ("PCI: Remove
untested Electromechanical Interlock (EMI) support in pciehp."), which
removes the definition of "struct hotplug_slot_attr", broke SGI
hotplug driver. By this commit, we get the following compile error.

drivers/pci/hotplug/sgi_hotplug.c:106: error: variable 'sn_slot_path_attr' has initializer but incomplete type
drivers/pci/hotplug/sgi_hotplug.c:106: error: unknown field 'attr' specified in initializer
drivers/pci/hotplug/sgi_hotplug.c:106: error: extra brace group at end of initializer
drivers/pci/hotplug/sgi_hotplug.c:106: error: (near initialization for 'sn_slot_path_attr')
drivers/pci/hotplug/sgi_hotplug.c:106: warning: excess elements in struct initializer
drivers/pci/hotplug/sgi_hotplug.c:106: warning: (near initialization for 'sn_slot_path_attr')
drivers/pci/hotplug/sgi_hotplug.c:106: error: unknown field 'show' specified in initializer
drivers/pci/hotplug/sgi_hotplug.c:106: warning: excess elements in struct initializer
drivers/pci/hotplug/sgi_hotplug.c:106: warning: (near initialization for 'sn_slot_path_attr')
drivers/pci/hotplug/sgi_hotplug.c: In function 'sn_hp_destroy':
drivers/pci/hotplug/sgi_hotplug.c:203: error: invalid use of undefined type 'struct hotplug_slot_attribute'
drivers/pci/hotplug/sgi_hotplug.c: In function 'sn_hotplug_slot_register':
drivers/pci/hotplug/sgi_hotplug.c:655: error: invalid use of undefined type 'struct hotplug_slot_attribute'

This patch fixes this regression by adding the definition of struct
hotplug_slot_attr into sgi_hotplug.c.

Tested-by: Mike Habeck 
Signed-off-by: Kenji Kaneshige 
Signed-off-by: Jesse Barnes

intel-iommu: Fix enabling snooping feature by mistake

2009-08-06T10:35:50+00:00

Two defects work together result in KVM device passthrough randomly can't
work:
1. iommu_snooping is not initialized to zero when vm_iommu_init() called.
So it is possible to get a random value.
2. One line added by commit 2c2e2c38("IOMMU Identity Mapping Support")
change the code path, let it bypass domain_update_iommu_cap(), as well as
missing the increment of domain iommu reference count.

The latter is also likely to cause a leak of domains on repeated VMM 
assignment and deassignment.

Signed-off-by: Sheng Yang 
Signed-off-by: David Woodhouse

intel-iommu: Mask physical address to correct page size in intel_map_single()

2009-08-05T08:15:48+00:00

The physical address passed to domain_pfn_mapping() should be rounded 
down to the start of the MM page, not the VT-d page.

This issue causes kernel panic on PAGE_SIZE>VTD_PAGE_SIZE platforms e.g. ia64
platforms.

Signed-off-by: Fenghua Yu 
Signed-off-by: David Woodhouse

intel-iommu: Correct sglist size calculation.

2009-08-05T07:59:47+00:00

In domain_sg_mapping(), use aligned_nrpages() instead of hand-coded
rounding code for calculating the size of each sg elem. This means that
on IA64 we correctly round up to the MM page size, not just to the VT-d
page size.

Also remove the incorrect mm_to_dma_pfn() when intel_map_sg() calls
domain_sg_mapping() -- the 'size' variable is in VT-d pages already.

Signed-off-by: Fenghua Yu 
Signed-off-by: David Woodhouse

Make pci_claim_resource() use request_resource() rather than insert_resource()

2009-08-02T21:10:18+00:00

This function has traditionally used "insert_resource()", because before
commit cebd78a8c5 ("Fix pci_claim_resource") it used to just insert the
resource into whatever root resource tree that was indicated by
"pcibios_select_root()".

So there Matthew fixed it to actually look up the proper parent
resource, which means that now it's actively wrong to then traverse the
resource tree any more: we already know exactly where the new resource
should go.

And when we then did commit a76117dfd6 ("x86: Use pci_claim_resource"),
which changed the x86 PCI code from the open-coded

	pr = pci_find_parent_resource(dev, r);
	if (!pr || request_resource(pr, r) < 0) {

to using

	if (pci_claim_resource(dev, idx) < 0) {

that "insert_resource()" now suddenly became a problem, and causes a
regression covered by

	http://bugzilla.kernel.org/show_bug.cgi?id=13891

which this fixes.

Reported-and-tested-by: Rafael J. Wysocki 
Cc: Matthew Wilcox 
Cc: Andrew Patterson 
Cc: Linux PCI 
Signed-off-by: Linus Torvalds

headers: smp_lock.h redux

2009-07-12T19:22:34+00:00

* Remove smp_lock.h from files which don't need it (including some headers!)
* Add smp_lock.h to files which do need it
* Make smp_lock.h include conditional in hardirq.h
  It's needed only for one kernel_locked() usage which is under CONFIG_PREEMPT

  This will make hardirq.h inclusion cheaper for every PREEMPT=n config
  (which includes allmodconfig/allyesconfig, BTW)

Signed-off-by: Alexey Dobriyan 
Signed-off-by: Linus Torvalds