1. 09 5月, 2011 1 次提交
  2. 23 11月, 2010 3 次提交
  3. 27 10月, 2010 3 次提交
    • T
      ide: clean up timed out request handling · dd8717da
      Tejun Heo 提交于
      8f6205cd introduced a bug where a
      timed out DMA request is never requeued and lost.
      6072f749 fixed this by making
      ide_dma_timeout_retry() requeue the request itself.  While the fix is
      correct, it makes DMA and non-DMA paths asymmetric regarding how the
      in flight request is requeued.
      
      As long as hwif->rq is set, the IDE driver is assuming ownership of
      the request and the request should either be completed or requeued
      when clearing hwif->rq.  In the timeout path, the ide driver holds
      onto the request as long as the recovery action (ie. reset) is in
      progress and clears it after the state machine is stopped (ide_stopped
      return), so the existing requeueing logic is correct.  The bug
      occurred because ide_dma_timeout_retry() explicitly clears hwif->rq
      without requeueing it.
      
      ide_dma_timeout_retry() is called only by ide_timer_expiry() and
      returns ide_started only when ide_error() would return it - ie. after
      reset state machine has started in which case the state machine will
      eventually end up executing the ide_stopped path in ide_timer_expiry()
      after reset protocol is complete.  So, there is no need to clear
      hwif->rq from ide_dma_timeout_retry().  ide_timer_expiry() will handle
      it the same way as PIO timeout path.
      
      Kill hwif->rq clearing and requeueing from ide_dma_timeout_retry() and
      let ide_timer_expiry() deal with it.  The end result should remain the
      same.
      
      grepping shows ide_dma_timeout_retry() is the only site which clears
      hwif->rq without taking care of the request, so there shouldn't be
      similar fallouts.
      Signed-off-by: NTejun Heo <tj@kernel.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      dd8717da
    • S
      hpt366: fix clock turnaround · bbe54d78
      Sergei Shtylyov 提交于
      DPLL clock (0x21) should be used for writes and PCI clock (0x23) for reads,
      not vice versa.
      Signed-off-by: NSergei Shtylyov <sshtylyov@ru.mvista.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      bbe54d78
    • S
      hpt366: add debounce delay to cable_detect() method · 5d3f1a49
      Sergei Shtylyov 提交于
      Alan Cox reported that cable detection sometimes works unreliably
      for HPT3xxN and that the issue is fixed by adding debounce delay
      as used by the vendor drivers.
      
      While at it, get rid of unneeded parens/space in the vicinity...
      Signed-off-by: NSergei Shtylyov <sshtylyov@ru.mvista.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      5d3f1a49
  4. 26 10月, 2010 33 次提交