1. 31 8月, 2010 2 次提交
    • G
      dccp ccid-3: use per-route RTO or TCP RTO as fallback · 89858ad1
      Gerrit Renker 提交于
      This makes RTAX_RTO_MIN also available to CCID-3, replacing the compile-time
      RTO lower bound with a per-route tunable value.
      
      The original Kconfig option solved the problem that a very low RTT (in the
      order of HZ) can trigger too frequent and unnecessary reductions of the
      sending rate.
      
      This tunable does not affect the initial RTO value of 2 seconds specified in
      RFC 5348, section 4.2 and Appendix B. But like the hardcoded Kconfig value,
      it allows to adapt to network conditions.
      
      The same effect as the original Kconfig option of 100ms is now achieved by
      
      > ip route replace to unicast 192.168.0.0/24 rto_min 100j dev eth0
      
      (assuming HZ=1000).
      Signed-off-by: NGerrit Renker <gerrit@erg.abdn.ac.uk>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      89858ad1
    • G
      dccp ccid-2: Share TCP's minimum RTO code · 4886fcad
      Gerrit Renker 提交于
      Using a fixed RTO_MIN of 0.2 seconds was found to cause problems for CCID-2
      over 802.11g: at least once per session there was a spurious timeout. It
      helped to then increase the the value of RTO_MIN over this link.
      
      Since the problem is the same as in TCP, this patch makes the solution from
      commit "05bb1fad"
             "[TCP]: Allow minimum RTO to be configurable via routing metrics."
      available to DCCP.
      
      This avoids reinventing the wheel, so that e.g. the following works in the
      expected way now also for CCID-2:
      
      > ip route change 10.0.0.2 rto_min 800 dev ath0
      
      Luckily this useful rto_min function was recently moved to net/tcp.h,
      which simplifies sharing code originating from TCP.
      
      Documentation also updated (plus minor whitespace fixes).
      Signed-off-by: NGerrit Renker <gerrit@erg.abdn.ac.uk>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      4886fcad
  2. 28 8月, 2010 1 次提交
  3. 25 8月, 2010 3 次提交
  4. 19 8月, 2010 1 次提交
  5. 15 8月, 2010 12 次提交
  6. 14 8月, 2010 1 次提交
  7. 12 8月, 2010 3 次提交
    • A
      mmc: add erase, secure erase, trim and secure trim operations · dfe86cba
      Adrian Hunter 提交于
      SD/MMC cards tend to support an erase operation.  In addition, eMMC v4.4
      cards can support secure erase, trim and secure trim operations that are
      all variants of the basic erase command.
      
      SD/MMC device attributes "erase_size" and "preferred_erase_size" have been
      added.
      
      "erase_size" is the minimum size, in bytes, of an erase operation.  For
      MMC, "erase_size" is the erase group size reported by the card.  Note that
      "erase_size" does not apply to trim or secure trim operations where the
      minimum size is always one 512 byte sector.  For SD, "erase_size" is 512
      if the card is block-addressed, 0 otherwise.
      
      SD/MMC cards can erase an arbitrarily large area up to and
      including the whole card.  When erasing a large area it may
      be desirable to do it in smaller chunks for three reasons:
      
          1. A single erase command will make all other I/O on the card
             wait.  This is not a problem if the whole card is being erased, but
             erasing one partition will make I/O for another partition on the
             same card wait for the duration of the erase - which could be a
             several minutes.
      
          2. To be able to inform the user of erase progress.
      
          3. The erase timeout becomes too large to be very useful.
             Because the erase timeout contains a margin which is multiplied by
             the size of the erase area, the value can end up being several
             minutes for large areas.
      
      "erase_size" is not the most efficient unit to erase (especially for SD
      where it is just one sector), hence "preferred_erase_size" provides a good
      chunk size for erasing large areas.
      
      For MMC, "preferred_erase_size" is the high-capacity erase size if a card
      specifies one, otherwise it is based on the capacity of the card.
      
      For SD, "preferred_erase_size" is the allocation unit size specified by
      the card.
      
      "preferred_erase_size" is in bytes.
      Signed-off-by: NAdrian Hunter <adrian.hunter@nokia.com>
      Acked-by: NJens Axboe <axboe@kernel.dk>
      Cc: Kyungmin Park <kmpark@infradead.org>
      Cc: Madhusudhan Chikkature <madhu.cr@ti.com>
      Cc: Christoph Hellwig <hch@lst.de>
      Cc: Ben Gardiner <bengardiner@nanometrics.ca>
      Cc: <linux-mmc@vger.kernel.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      dfe86cba
    • P
      dm: allow autoloading of dm mod · 7e507eb6
      Peter Rajnoha 提交于
      Add devname:mapper/control and MAPPER_CTRL_MINOR module alias
      to support dm-mod module autoloading.
      Signed-off-by: NKay Sievers <kay.sievers@vrfy.org>
      Signed-off-by: NPeter Rajnoha <prajnoha@redhat.com>
      Signed-off-by: NAlasdair G Kergon <agk@redhat.com>
      7e507eb6
    • J
      i2c: Add support for custom probe function · 9a94241a
      Jean Delvare 提交于
      The probe method used by i2c_new_probed_device() may not be suitable
      for all cases. Let the caller provide its own, optional probe
      function.
      Signed-off-by: NJean Delvare <khali@linux-fr.org>
      Acked-by: NMauro Carvalho Chehab <mchehab@redhat.com>
      9a94241a
  8. 11 8月, 2010 17 次提交