1. 05 Mar, 2007 5 commits
    • Eric W. Biederman's avatar
      [PATCH] msi: support masking msi irqs without a mask bit · 58e0543e
      Eric W. Biederman authored
      For devices that do not support msi-x we only support 1 interrupt.  Therefore
      we can disable that one interrupt by disabling the msi capability itself.  If
      we leave the intx interrupts disabled while we have the msi capability
      disabled no interrupts should be delivered from that device.
      
      Devices with just the minimal msi support (and thus hitting this code path)
      include things like the intel e1000 nic, so it looks like is going to be a
      fairly common case and thus important to get right.
      Signed-off-by: default avatarEric W. Biederman <ebiederm@xmission.com>
      Cc: Michael Ellerman <michael@ellerman.id.au>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Greg KH <greg@kroah.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      58e0543e
    • Eric W. Biederman's avatar
      [PATCH] msi: fix up the msi enable/disable logic · b1cbf4e4
      Eric W. Biederman authored
      enable/disable_msi_mode have several side effects which keeps them from being
      generally useful.  So this patch replaces them with with two much more
      targeted functions: msi_set_enable and msix_set_enable.
      
      This patch makes pci_dev->msi_enabled and pci_dev->msix_enabled the definitive
      way to test if linux has enabled the msi capability, and has the appropriate
      msi data structures set up.
      
      This patch ensures that while writing the msi messages in save/restore and
      during device initialization we have the msi capability disabled so we don't
      get into races.  The pci spec requires that we do not have the msi capability
      enabled and the msi messages unmasked while we write the messages.  Completely
      disabling the capability is overkill but it is easy :)
      
      Care has been taken so we never have both a msi capability and intx enabled
      simultaneously.  We haven't run into a problem yet but better safe then sorry.
      Signed-off-by: default avatarEric W. Biederman <ebiederm@xmission.com>
      Cc: Michael Ellerman <michael@ellerman.id.au>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Greg KH <greg@kroah.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      b1cbf4e4
    • Eric W. Biederman's avatar
      [PATCH] msi: sanely support hardware level msi disabling · f5f2b131
      Eric W. Biederman authored
      In some cases when we are not using msi we need a way to ensure that the
      hardware does not have an msi capability enabled.  Currently the code has been
      calling disable_msi_mode to try and achieve that.  However disable_msi_mode
      has several other side effects and is only available when msi support is
      compiled in so it isn't really appropriate.
      
      Instead this patch implements pci_msi_off which disables all msi and msix
      capabilities unconditionally with no additional side effects.
      
      pci_disable_device was redundantly clearing the bus master enable flag and
      clearing the msi enable bit.  A device that is not allowed to perform bus
      mastering operations cannot generate intx or msi interrupt messages as those
      are essentially a special case of dma, and require bus mastering.  So the call
      in pci_disable_device to disable msi capabilities was redundant.
      
      quirk_pcie_pxh also called disable_msi_mode and is updated to use pci_msi_off.
      Signed-off-by: default avatarEric W. Biederman <ebiederm@xmission.com>
      Cc: Michael Ellerman <michael@ellerman.id.au>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Greg KH <greg@kroah.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      f5f2b131
    • Jean Delvare's avatar
      [PATCH] io_apic.h needs apicdef.h · 58a53b24
      Jean Delvare authored
      A -mm patch caused:
      
      In file included from drivers/pci/quirks.c:532:
      include/asm/io_apic.h:61: error: "MAX_IO_APICS" undeclared here (not in a function)
      
      So let's include the needed header.
      Signed-off-by: default avatarJean Delvare <khali@linux-fr.org>
      Cc: Andi Kleen <ak@suse.de>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      58a53b24
    • Andrew Morton's avatar
      [PATCH] cyclades: return closing_wait · d5dedf99
      Andrew Morton authored
      In http://bugzilla.kernel.org/show_bug.cgi?id=8065, Shen points out that the
      cyclades driver forget to return closing_wait to userspace.
      
      Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
      Cc: Russell King <rmk@arm.linux.org.uk>
      Cc: Shen <shanlu@cs.uiuc.edu>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      d5dedf99
  2. 04 Mar, 2007 35 commits