Skip to content

K
Kernel

openeuler / Kernel
1 年多 前同步成功

通知 8
Star 0
Fork 0
K
Kernel
切换分支/标签
  1. 30 5月, 2014 1 次提交
  3. 20 2月, 2014 1 次提交
  5. 11 1月, 2014 1 次提交
  7. 23 11月, 2013 1 次提交
    • E
      PCI: Clear NumVFs when disabling SR-IOV in sriov_init() · 045cc22e
      由 ethan.zhao 提交于 
      When SR-IOV is disabled (VF Enable is cleared), NumVFs is not very useful,
so this patch clears it out to prevent confusing lspci output like that
below.  We already clear NumVFs in sriov_disable(), and this does the same
when we disable SR-IOV as part of parsing the SR-IOV capability.

  $ lspci -vvv -s 13:00.0
  13:00.0 Ethernet controller: Intel Corporation 82599EB 10-Gigabit SFI/SFP+ Network Connection (rev 01)
      Capabilities: [160 v1] Single Root I/O Virtualization (SR-IOV)
          IOVCtl: Enable- Migration- Interrupt- MSE- ARIHierarchy+
          Initial VFs: 64, Total VFs: 64, Number of VFs: 64, ...

[bhelgaas: changelog]
Signed-off-by: Nethan.zhao <ethan.kernel@gmail.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
      045cc22e
  9. 15 11月, 2013 1 次提交
  11. 01 8月, 2013 1 次提交
  13. 31 7月, 2013 1 次提交
  15. 26 7月, 2013 1 次提交
  17. 15 6月, 2013 2 次提交
  19. 06 6月, 2013 1 次提交
    • G
      PCI: Convert alloc_pci_dev(void) to pci_alloc_dev(bus) · 8b1fce04
      由 Gu Zheng 提交于 
      Use the new pci_alloc_dev(bus) to replace the existing using of
alloc_pci_dev(void).

[bhelgaas: drop pci_bus ref later in pci_release_dev()]
Signed-off-by: NGu Zheng <guz.fnst@cn.fujitsu.com>
Signed-off-by: NJiang Liu <jiang.liu@huawei.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Paul Mackerras <paulus@samba.org>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: David Airlie <airlied@linux.ie>
Cc: Neela Syam Kolli <megaraidlinux@lsi.com>
Cc: "James E.J. Bottomley" <JBottomley@parallels.com>
Cc: Yinghai Lu <yinghai@kernel.org>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Andrew Morton <akpm@linux-foundation.org>
      8b1fce04
  21. 01 6月, 2013 1 次提交
    • X
      PCI: Finish SR-IOV VF setup before adding the device · fbf33f51
      由 Xudong Hao 提交于 
      Commit 4f535093 "PCI: Put pci_dev in device tree as early as possible"
moves device registering from pci_bus_add_devices() to pci_device_add().
That causes problems for virtual functions because device_add(&virtfn->dev)
is called before setting the virtfn->is_virtfn flag, which then causes Xen
to report PCI virtual functions as PCI physical functions.

Fix it by setting virtfn->is_virtfn before calling pci_device_add().

[Jiang Liu]: Move the setting of virtfn->is_virtfn ahead further for better
readability and modify changelog.
Signed-off-by: NXudong Hao <xudong.hao@intel.com>
Signed-off-by: NJiang Liu <jiang.liu@huawei.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Cc: stable@vger.kernel.org	# v3.9+
      fbf33f51
  23. 25 4月, 2013 1 次提交
  25. 02 2月, 2013 1 次提交
  27. 26 1月, 2013 1 次提交
    • Y
      PCI: Put pci_dev in device tree as early as possible · 4f535093
      由 Yinghai Lu 提交于 
      We want to put pci_dev structs in the device tree as soon as possible so
for_each_pci_dev() iteration will not miss them, but driver attachment
needs to be delayed until after pci_assign_unassigned_resources() to make
sure all devices have resources assigned first.

This patch moves device registering from pci_bus_add_devices() to
pci_device_add(), which happens earlier, leaving driver attachment in
pci_bus_add_devices().

It also removes unattached child bus handling in pci_bus_add_devices().
That's not needed because child bus via pci_add_new_bus() is already
in parent bus children list.

[bhelgaas: changelog]
Signed-off-by: NYinghai Lu <yinghai@kernel.org>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Acked-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      4f535093
  29. 11 1月, 2013 1 次提交
  31. 10 11月, 2012 3 次提交
  33. 21 9月, 2012 1 次提交
    • B
      Revert "PCI: Use hotplug-safe pci_get_domain_bus_and_slot()" · 94bb3464
      由 Bjorn Helgaas 提交于 
      This reverts commit 433efd22.

When we remove an SR-IOV device, we have this call chain:

    driver .remove() method
        pci_disable_sriov()
            sriov_disable()
                virtfn_remove()
                    pci_get_domain_bus_and_slot()

sriov_disable() is only called for PFs, not for VFs.  When it's called
for a PF, it loops through all the VFs and calls virtfn_remove() for
each.  But we stop and remove VFs before PFs, so by the time we get
to virtfn_remove(), the VFs have already been stopped and deleted
from the device list.  Now pci_get_domain_bus_and_slot(), which uses
bus_find_device() and relies on that device list, doesn't find the
VFs, so the VF references aren't released correctly.
Reported-by: NYinghai Lu <yinghai@kernel.org>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
      94bb3464
  35. 13 9月, 2012 1 次提交
  37. 23 8月, 2012 1 次提交
  39. 14 6月, 2012 2 次提交
  41. 28 2月, 2012 1 次提交
  43. 18 2月, 2012 1 次提交
  45. 11 2月, 2012 1 次提交
  47. 07 1月, 2012 2 次提交
    • R
      PCI: delay configuration of SRIOV capability · afd24ece
      由 Ram Pai 提交于 
      The SRIOV capability, namely page size and total_vfs of a device are
configured during enumeration phase of the device.  This can potentially
interfere with the PCI operations of the platform, if the IOV capability
of the device is not enabled.

The following patch postpones the configuration of the IOV capability of
the device to a later point, when the IOV capability is explicitly
enabled by the device driver.

The patch is tested on x86 and power platform.
Tested-by: NDonald Dutile <ddutile@redhat.com>
Signed-off-by: NRam Pai <linuxram@us.ibm.com>
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
      afd24ece
    • J
      PCI: Rework config space blocking services · fb51ccbf
      由 Jan Kiszka 提交于 
      pci_block_user_cfg_access was designed for the use case that a single
context, the IPR driver, temporarily delays user space accesses to the
config space via sysfs. This assumption became invalid by the time
pci_dev_reset was added as locking instance. Today, if you run two loops
in parallel that reset the same device via sysfs, you end up with a
kernel BUG as pci_block_user_cfg_access detect the broken assumption.

This reworks the pci_block_user_cfg_access to a sleeping service
pci_cfg_access_lock and an atomic-compatible variant called
pci_cfg_access_trylock. The former not only blocks user space access as
before but also waits if access was already locked. The latter service
just returns false in this case, allowing the caller to resolve the
conflict instead of raising a BUG.

Adaptions of the ipr driver were originally written by Brian King.
Acked-by: NBrian King <brking@linux.vnet.ibm.com>
Acked-by: NMichael S. Tsirkin <mst@redhat.com>
Signed-off-by: NJan Kiszka <jan.kiszka@siemens.com>
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
      fb51ccbf
  49. 06 12月, 2011 1 次提交
    • R
      PCI: defer enablement of SRIOV BARS · bbef98ab
      由 Ram Pai 提交于 
      All the PCI BARs of a device are enabled when the device is enabled
using pci_enable_device().  This unnecessarily enables SRIOV BARs of the
device.

On some platforms, which do not support SRIOV as yet, the
pci_enable_device() fails to enable the device if its SRIOV BARs are not
allocated resources correctly.

The following patch fixes the above problem. The SRIOV BARs are now
enabled when IOV capability of the device is enabled in sriov_enable().

NOTE: Note, there is subtle change in the pci_enable_device() API.  Any
driver that depends on SRIOV BARS to be enabled in pci_enable_device()
can fail.

The patch has been touch tested on power and x86 platform.
Tested-by: NMichael Wang <wangyun@linux.vnet.ibm.com>
Signed-off-by: NRam Pai <linuxram@us.ibm.com>
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
      bbef98ab
  51. 01 11月, 2011 1 次提交
  53. 15 10月, 2011 1 次提交
  55. 11 4月, 2011 1 次提交
  57. 10 9月, 2010 1 次提交
  59. 30 3月, 2010 1 次提交
    • T
      include cleanup: Update gfp.h and slab.h includes to prepare for breaking... · 5a0e3ad6
      由 Tejun Heo 提交于 
      include cleanup: Update gfp.h and slab.h includes to prepare for breaking implicit slab.h inclusion from percpu.h

percpu.h is included by sched.h and module.h and thus ends up being
included when building most .c files.  percpu.h includes slab.h which
in turn includes gfp.h making everything defined by the two files
universally available and complicating inclusion dependencies.

percpu.h -> slab.h dependency is about to be removed.  Prepare for
this change by updating users of gfp and slab facilities include those
headers directly instead of assuming availability.  As this conversion
needs to touch large number of source files, the following script is
used as the basis of conversion.

  http://userweb.kernel.org/~tj/misc/slabh-sweep.py

The script does the followings.

* Scan files for gfp and slab usages and update includes such that
  only the necessary includes are there.  ie. if only gfp is used,
  gfp.h, if slab is used, slab.h.

* When the script inserts a new include, it looks at the include
  blocks and try to put the new include such that its order conforms
  to its surrounding.  It's put in the include block which contains
  core kernel includes, in the same order that the rest are ordered -
  alphabetical, Christmas tree, rev-Xmas-tree or at the end if there
  doesn't seem to be any matching order.

* If the script can't find a place to put a new include (mostly
  because the file doesn't have fitting include block), it prints out
  an error message indicating which .h file needs to be added to the
  file.

The conversion was done in the following steps.

1. The initial automatic conversion of all .c files updated slightly
   over 4000 files, deleting around 700 includes and adding ~480 gfp.h
   and ~3000 slab.h inclusions.  The script emitted errors for ~400
   files.

2. Each error was manually checked.  Some didn't need the inclusion,
   some needed manual addition while adding it to implementation .h or
   embedding .c file was more appropriate for others.  This step added
   inclusions to around 150 files.

3. The script was run again and the output was compared to the edits
   from #2 to make sure no file was left behind.

4. Several build tests were done and a couple of problems were fixed.
   e.g. lib/decompress_*.c used malloc/free() wrappers around slab
   APIs requiring slab.h to be added manually.

5. The script was run on all .h files but without automatically
   editing them as sprinkling gfp.h and slab.h inclusions around .h
   files could easily lead to inclusion dependency hell.  Most gfp.h
   inclusion directives were ignored as stuff from gfp.h was usually
   wildly available and often used in preprocessor macros.  Each
   slab.h inclusion directive was examined and added manually as
   necessary.

6. percpu.h was updated not to include slab.h.

7. Build test were done on the following configurations and failures
   were fixed.  CONFIG_GCOV_KERNEL was turned off for all tests (as my
   distributed build env didn't work with gcov compiles) and a few
   more options had to be turned off depending on archs to make things
   build (like ipr on powerpc/64 which failed due to missing writeq).

   * x86 and x86_64 UP and SMP allmodconfig and a custom test config.
   * powerpc and powerpc64 SMP allmodconfig
   * sparc and sparc64 SMP allmodconfig
   * ia64 SMP allmodconfig
   * s390 SMP allmodconfig
   * alpha SMP allmodconfig
   * um on x86_64 SMP allmodconfig

8. percpu.h modifications were reverted so that it could be applied as
   a separate patch and serve as bisection point.

Given the fact that I had only a couple of failures from tests on step
6, I'm fairly confident about the coverage of this conversion patch.
If there is a breakage, it's likely to be something in one of the arch
headers which should be easily discoverable easily on most builds of
the specific arch.
Signed-off-by: NTejun Heo <tj@kernel.org>
Guess-its-ok-by: NChristoph Lameter <cl@linux-foundation.org>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Lee Schermerhorn <Lee.Schermerhorn@hp.com>
      5a0e3ad6
  61. 13 2月, 2010 1 次提交
  63. 25 11月, 2009 1 次提交
  65. 30 8月, 2009 1 次提交
    • C
      PCI SR-IOV: correct broken resource alignment calculations · 6faf17f6
      由 Chris Wright 提交于 
      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: NChris Wright <chrisw@sous-sol.org>
Cc: Ivan Kokshaysky <ink@jurassic.park.msu.ru>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Matthew Wilcox <matthew@wil.cx>
Cc: Yu Zhao <yu.zhao@intel.com>
Cc: stable@kernel.org
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
      6faf17f6
  67. 17 6月, 2009 1 次提交
  69. 12 6月, 2009 1 次提交
    • Y
      PCI: fix SR-IOV function dependency link problem · 4d135dbe
      由 Yu Zhao 提交于 
      PCIe root complex integrated endpoint does not implement ARI, so this
kind of endpoint uses 3-bit function number. The function dependency
link of the integrated endpoint should be calculated using the device
number plus the value from function dependency link register.

Normal endpoint always implements ARI and the function dependency link
register contains 8-bit function number (i.e. `devfn' from software's
perspective).
Signed-off-by: NYu Zhao <yu.zhao@intel.com>
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
      4d135dbe