1. 14 10月, 2009 1 次提交
    • T
      inifiband: Remove BKL from ipath_open() · f96d3015
      Thomas Gleixner 提交于
      cycle_kernel_lock() got pushed down to ipath_open(). I tried hard to
      understand what it might protect, but finally gave up.
      
      Roland noted that qlogic seems to have abandoned the ipath driver and
      came to the following wise conclusion: "So I guess if the BKL stuff is
      blocking you in any way, we can just drop it from ipath and leave it
      as yet another race condition in a rotting old driver."
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      LKML-Reference: <adad44tj090.fsf@cisco.com>
      Cc: Roland Dreier <rdreier@cisco.com>
      f96d3015
  2. 28 9月, 2009 1 次提交
  3. 06 9月, 2009 1 次提交
  4. 30 12月, 2008 1 次提交
  5. 06 12月, 2008 2 次提交
  6. 17 10月, 2008 1 次提交
  7. 22 7月, 2008 1 次提交
  8. 21 6月, 2008 2 次提交
  9. 14 5月, 2008 1 次提交
    • P
      IB/ipath: Make ipath_portdata work with struct pid * not pid_t · 40d97692
      Pavel Emelyanov 提交于
      The official reason is "with the presence of pid namespaces in the
      kernel using pid_t-s inside one is no longer safe."
      
      But the reason I fix this right now is the following:
      
      About a month ago (when 2.6.25 was not yet released) there still was a
      one last caller of a to-be-deprecated-soon function find_pid() - the
      kill_proc() function, which in turn was only used by nfs callback
      code.
      
      During the last merge window, this last caller was finally eliminated
      by some NFS patch(es) and I was about to finally kill this kill_proc()
      and find_pid(), but found, that I was late and the kill_proc is now
      called from the ipath driver since commit 58411d1c ("IB/ipath: Head of
      Line blocking vs forward progress of user apps").
      
      So here's a patch that fixes this code to use struct pid * and (!)
      the kill_pid routine.
      Signed-off-by: NPavel Emelyanov <xemul@openvz.org>
      Signed-off-by: NRoland Dreier <rolandd@cisco.com>
      40d97692
  10. 08 5月, 2008 1 次提交
    • D
      IB/ipath: Need to always request and handle PIO avail interrupts · e2ab41ca
      Dave Olson 提交于
      Now that we always use PIO for vl15 on 7220, we could get stuck forever
      if we happened to run out of PIO buffers from the verbs code, because
      the setup code wouldn't run; the interrupt was also ignored if SDMA was
      supported.  We also have to reduce the pio update threshold if we have
      fewer kernel buffers than the existing threshold.
      
      Clean up the initialization a bit to get ordering safer and more
      sensible, and use the existing ipath_chg_kernavail call to do init,
      rather than doing it separately.
      
      Drop unnecessary clearing of pio buffer on pio parity error.
      
      Drop incorrect updating of pioavailshadow when exitting freeze mode
      (software state may not match chip state if buffer has been allocated
      and not yet written).
      
      If we couldn't get a kernel buffer for a while, make sure we are
      in sync with hardware, mainly to handle the exitting freeze case.
      Signed-off-by: NDave Olson <dave.olson@qlogic.com>
      Signed-off-by: NRoland Dreier <rolandd@cisco.com>
      e2ab41ca
  11. 20 4月, 2008 1 次提交
  12. 17 4月, 2008 8 次提交
  13. 26 1月, 2008 9 次提交
  14. 10 10月, 2007 2 次提交
  15. 10 7月, 2007 4 次提交
  16. 19 4月, 2007 4 次提交