1. 04 1月, 2014 3 次提交
  2. 21 12月, 2013 2 次提交
  3. 20 12月, 2013 1 次提交
  4. 15 11月, 2013 1 次提交
  5. 07 11月, 2013 1 次提交
    • K
      PCI: Add x86_msi.msi_mask_irq() and msix_mask_irq() · 0e4ccb15
      Konrad Rzeszutek Wilk 提交于
      Certain platforms do not allow writes in the MSI-X BARs to setup or tear
      down vector values.  To combat against the generic code trying to write to
      that and either silently being ignored or crashing due to the pagetables
      being marked R/O this patch introduces a platform override.
      
      Note that we keep two separate, non-weak, functions default_mask_msi_irqs()
      and default_mask_msix_irqs() for the behavior of the arch_mask_msi_irqs()
      and arch_mask_msix_irqs(), as the default behavior is needed by x86 PCI
      code.
      
      For Xen, which does not allow the guest to write to MSI-X tables - as the
      hypervisor is solely responsible for setting the vector values - we
      implement two nops.
      
      This fixes a Xen guest crash when passing a PCI device with MSI-X to the
      guest.  See the bugzilla for more details.
      
      [bhelgaas: add bugzilla info]
      Reference: https://bugzilla.kernel.org/show_bug.cgi?id=64581Signed-off-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>
      Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
      CC: Sucheta Chakraborty <sucheta.chakraborty@qlogic.com>
      CC: Zhenzhong Duan <zhenzhong.duan@oracle.com>
      0e4ccb15
  6. 30 10月, 2013 1 次提交
  7. 13 9月, 2013 1 次提交
  8. 13 8月, 2013 1 次提交
  9. 12 8月, 2013 2 次提交
  10. 29 5月, 2013 1 次提交
    • A
      PCI: Allocate only as many MSI vectors as requested by driver · 65f6ae66
      Alexander Gordeev 提交于
      Because of the encoding of the "Multiple Message Capable" and "Multiple
      Message Enable" fields, a device can only advertise that it's capable of a
      power-of-two number of vectors, and the OS can only enable a power-of-two
      number.
      
      For example, a device that's limited internally to using 18 vectors would
      have to advertise that it's capable of 32.  The 14 extra vectors consume
      vector numbers and IRQ descriptors even though the device can't actually
      use them.
      
      This fix introduces a 'msi_desc::nvec_used' field to address this issue.
      When non-zero, it is the actual number of MSIs the device will send, as
      requested by the device driver.  This value should be used by architectures
      to set up and tear down only as many interrupt resources as the device will
      actually use.
      
      Note, although the existing 'msi_desc::multiple' field might seem
      redundant, in fact it is not.  The number of MSIs advertised need not be
      the smallest power-of-two larger than the number of MSIs the device will
      send.  Thus, it is not always possible to derive the former from the
      latter, so we need to keep them both to handle this case.
      
      [bhelgaas: changelog, rename to "nvec_used"]
      Signed-off-by: NAlexander Gordeev <agordeev@redhat.com>
      Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
      65f6ae66
  11. 30 4月, 2013 1 次提交
  12. 23 4月, 2013 13 次提交
  13. 13 4月, 2013 1 次提交
  14. 25 1月, 2013 1 次提交
  15. 01 12月, 2012 1 次提交
    • J
      s390/pci: PCI adapter interrupts for MSI/MSI-X · 9a4da8a5
      Jan Glauber 提交于
      Support PCI adapter interrupts using the Single-IRQ-mode. Single-IRQ-mode
      disables an adapter IRQ automatically after delivering it until the SIC
      instruction enables it again. This is used to reduce the number of IRQs
      for streaming workloads.
      
      Up to 64 MSI handlers can be registered per PCI function.
      A hash table is used to map interrupt numbers to MSI descriptors.
      The interrupt vector is scanned using the flogr instruction.
      Only MSI/MSI-X interrupts are supported, no legacy INTs.
      Signed-off-by: NJan Glauber <jang@linux.vnet.ibm.com>
      Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>
      9a4da8a5
  16. 07 1月, 2012 4 次提交
    • K
      x86/PCI: Expand the x86_msi_ops to have a restore MSIs. · 76ccc297
      Konrad Rzeszutek Wilk 提交于
      The MSI restore function will become a function pointer in an
      x86_msi_ops struct. It defaults to the implementation in the
      io_apic.c and msi.c. We piggyback on the indirection mechanism
      introduced by "x86: Introduce x86_msi_ops".
      
      Cc: x86@kernel.org
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      Cc: linux-pci@vger.kernel.org
      Signed-off-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>
      Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
      76ccc297
    • N
      PCI: msi: fix imbalanced refcount of msi irq sysfs objects · 424eb391
      Neil Horman 提交于
      This warning was recently reported to me:
      
      ------------[ cut here ]------------
      WARNING: at lib/kobject.c:595 kobject_put+0x50/0x60()
      Hardware name: VMware Virtual Platform
      kobject: '(null)' (ffff880027b0df40): is not initialized, yet kobject_put() is
      being called.
      Modules linked in: vmxnet3(+) vmw_balloon i2c_piix4 i2c_core shpchp raid10
      vmw_pvscsi
      Pid: 630, comm: modprobe Tainted: G        W   3.1.6-1.fc16.x86_64 #1
      Call Trace:
       [<ffffffff8106b73f>] warn_slowpath_common+0x7f/0xc0
       [<ffffffff8106b836>] warn_slowpath_fmt+0x46/0x50
       [<ffffffff810da293>] ? free_desc+0x63/0x70
       [<ffffffff812a9aa0>] kobject_put+0x50/0x60
       [<ffffffff812e4c25>] free_msi_irqs+0xd5/0x120
       [<ffffffff812e524c>] pci_enable_msi_block+0x24c/0x2c0
       [<ffffffffa017c273>] vmxnet3_alloc_intr_resources+0x173/0x240 [vmxnet3]
       [<ffffffffa0182e94>] vmxnet3_probe_device+0x615/0x834 [vmxnet3]
       [<ffffffff812d141c>] local_pci_probe+0x5c/0xd0
       [<ffffffff812d2cb9>] pci_device_probe+0x109/0x130
       [<ffffffff8138ba2c>] driver_probe_device+0x9c/0x2b0
       [<ffffffff8138bceb>] __driver_attach+0xab/0xb0
       [<ffffffff8138bc40>] ? driver_probe_device+0x2b0/0x2b0
       [<ffffffff8138bc40>] ? driver_probe_device+0x2b0/0x2b0
       [<ffffffff8138a8ac>] bus_for_each_dev+0x5c/0x90
       [<ffffffff8138b63e>] driver_attach+0x1e/0x20
       [<ffffffff8138b240>] bus_add_driver+0x1b0/0x2a0
       [<ffffffffa0188000>] ? 0xffffffffa0187fff
       [<ffffffff8138c246>] driver_register+0x76/0x140
       [<ffffffff815ca414>] ? printk+0x51/0x53
       [<ffffffffa0188000>] ? 0xffffffffa0187fff
       [<ffffffff812d2996>] __pci_register_driver+0x56/0xd0
       [<ffffffffa018803a>] vmxnet3_init_module+0x3a/0x3c [vmxnet3]
       [<ffffffff81002042>] do_one_initcall+0x42/0x180
       [<ffffffff810aad71>] sys_init_module+0x91/0x200
       [<ffffffff815dccc2>] system_call_fastpath+0x16/0x1b
      ---[ end trace 44593438a59a9558 ]---
      Using INTx interrupt, #Rx queues: 1.
      
      It occurs when populate_msi_sysfs fails, which in turn causes free_msi_irqs to
      be called.  Because populate_msi_sysfs fails, we never registered any of the
      msi irq sysfs objects, but free_msi_irqs still calls kobject_del and kobject_put
      on each of them, which gets flagged in the above stack trace.
      
      The fix is pretty straightforward.  We can key of the parent pointer in the
      kobject.  It is only set if the kobject_init_and_add succededs in
      populate_msi_sysfs.  If anything fails there, each kobject has its parent reset
      to NULL
      Signed-off-by: NNeil Horman <nhorman@tuxdriver.com>
      CC: Bjorn Helgaas <bhelgaas@google.com>
      CC: Greg Kroah-Hartman <gregkh@suse.de>
      CC: linux-pci@vger.kernel.org
      Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
      424eb391
    • E
      PCI: msi: Disable msi interrupts when we initialize a pci device · d5dea7d9
      Eric W. Biederman 提交于
      I traced a nasty kexec on panic boot failure to the fact that we had
      screaming msi interrupts and we were not disabling the msi messages at
      kernel startup.  The booting kernel had not enabled those interupts so
      was not prepared to handle them.
      
      I can see no reason why we would ever want to leave the msi interrupts
      enabled at boot if something else has enabled those interrupts.  The pci
      spec specifies that msi interrupts should be off by default.  Drivers
      are expected to enable the msi interrupts if they want to use them.  Our
      interrupt handling code reprograms the interrupt handlers at boot and
      will not be be able to do anything useful with an unexpected interrupt.
      
      This patch applies cleanly all of the way back to 2.6.32 where I noticed
      the problem.
      
      Cc: stable@kernel.org
      Signed-off-by: NEric W. Biederman <ebiederm@xmission.com>
      Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
      d5dea7d9
    • N
      PCI/sysfs: add per pci device msi[x] irq listing (v5) · da8d1c8b
      Neil Horman 提交于
      This patch adds a per-pci-device subdirectory in sysfs called:
      /sys/bus/pci/devices/<device>/msi_irqs
      
      This sub-directory exports the set of msi vectors allocated by a given
      pci device, by creating a numbered sub-directory for each vector beneath
      msi_irqs.  For each vector various attributes can be exported.
      Currently the only attribute is called mode, which tracks the
      operational mode of that vector (msi vs. msix)
      Acked-by: NGreg Kroah-Hartman <gregkh@suse.de>
      Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
      da8d1c8b
  17. 06 12月, 2011 2 次提交
    • E
      PCI: msi: Disable msi interrupts when we initialize a pci device · a776c491
      Eric W. Biederman 提交于
      I traced a nasty kexec on panic boot failure to the fact that we had
      screaming msi interrupts and we were not disabling the msi messages at
      kernel startup.  The booting kernel had not enabled those interupts so
      was not prepared to handle them.
      
      I can see no reason why we would ever want to leave the msi interrupts
      enabled at boot if something else has enabled those interrupts.  The pci
      spec specifies that msi interrupts should be off by default.  Drivers
      are expected to enable the msi interrupts if they want to use them.  Our
      interrupt handling code reprograms the interrupt handlers at boot and
      will not be be able to do anything useful with an unexpected interrupt.
      
      This patch applies cleanly all of the way back to 2.6.32 where I noticed
      the problem.
      
      Cc: stable@kernel.org
      Signed-off-by: NEric W. Biederman <ebiederm@xmission.com>
      Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
      a776c491
    • N
      PCI/sysfs: add per pci device msi[x] irq listing (v5) · b50cac55
      Neil Horman 提交于
      This patch adds a per-pci-device subdirectory in sysfs called:
      /sys/bus/pci/devices/<device>/msi_irqs
      
      This sub-directory exports the set of msi vectors allocated by a given
      pci device, by creating a numbered sub-directory for each vector beneath
      msi_irqs.  For each vector various attributes can be exported.
      Currently the only attribute is called mode, which tracks the
      operational mode of that vector (msi vs. msix)
      Acked-by: NGreg Kroah-Hartman <gregkh@suse.de>
      Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
      b50cac55
  18. 01 11月, 2011 1 次提交
  19. 29 3月, 2011 1 次提交
  20. 24 12月, 2010 1 次提交