Skip to content
Snippets Groups Projects
  1. Aug 29, 2009
    • Dan Williams's avatar
      async_tx: add support for asynchronous RAID6 recovery operations · 0a82a623
      Dan Williams authored
      
       async_raid6_2data_recov() recovers two data disk failures
      
       async_raid6_datap_recov() recovers a data disk and the P disk
      
      These routines are a port of the synchronous versions found in
      drivers/md/raid6recov.c.  The primary difference is breaking out the xor
      operations into separate calls to async_xor.  Two helper routines are
      introduced to perform scalar multiplication where needed.
      async_sum_product() multiplies two sources by scalar coefficients and
      then sums (xor) the result.  async_mult() simply multiplies a single
      source by a scalar.
      
      This implemention also includes, in contrast to the original
      synchronous-only code, special case handling for the 4-disk and 5-disk
      array cases.  In these situations the default N-disk algorithm will
      present 0-source or 1-source operations to dma devices.  To cover for
      dma devices where the minimum source count is 2 we implement 4-disk and
      5-disk handling in the recovery code.
      
      [ Impact: asynchronous raid6 recovery routines for 2data and datap cases ]
      
      Cc: Yuri Tikhonov <yur@emcraft.com>
      Cc: Ilya Yanok <yanok@emcraft.com>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: David Woodhouse <David.Woodhouse@intel.com>
      Reviewed-by: default avatarAndre Noll <maan@systemlinux.org>
      Acked-by: default avatarMaciej Sosnowski <maciej.sosnowski@intel.com>
      Signed-off-by: default avatarDan Williams <dan.j.williams@intel.com>
      
      0a82a623
    • Dan Williams's avatar
      async_tx: add support for asynchronous GF multiplication · b2f46fd8
      Dan Williams authored
      
      [ Based on an original patch by Yuri Tikhonov ]
      
      This adds support for doing asynchronous GF multiplication by adding
      two additional functions to the async_tx API:
      
       async_gen_syndrome() does simultaneous XOR and Galois field
          multiplication of sources.
      
       async_syndrome_val() validates the given source buffers against known P
          and Q values.
      
      When a request is made to run async_pq against more than the hardware
      maximum number of supported sources we need to reuse the previous
      generated P and Q values as sources into the next operation.  Care must
      be taken to remove Q from P' and P from Q'.  For example to perform a 5
      source pq op with hardware that only supports 4 sources at a time the
      following approach is taken:
      
      p, q = PQ(src0, src1, src2, src3, COEF({01}, {02}, {04}, {08}))
      p', q' = PQ(p, q, q, src4, COEF({00}, {01}, {00}, {10}))
      
      p' = p + q + q + src4 = p + src4
      q' = {00}*p + {01}*q + {00}*q + {10}*src4 = q + {10}*src4
      
      Note: 4 is the minimum acceptable maxpq otherwise we punt to
      synchronous-software path.
      
      The DMA_PREP_CONTINUE flag indicates to the driver to reuse p and q as
      sources (in the above manner) and fill the remaining slots up to maxpq
      with the new sources/coefficients.
      
      Note1: Some devices have native support for P+Q continuation and can skip
      this extra work.  Devices with this capability can advertise it with
      dma_set_maxpq.  It is up to each driver how to handle the
      DMA_PREP_CONTINUE flag.
      
      Note2: The api supports disabling the generation of P when generating Q,
      this is ignored by the synchronous path but is implemented by some dma
      devices to save unnecessary writes.  In this case the continuation
      algorithm is simplified to only reuse Q as a source.
      
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: David Woodhouse <David.Woodhouse@intel.com>
      Signed-off-by: default avatarYuri Tikhonov <yur@emcraft.com>
      Signed-off-by: default avatarIlya Yanok <yanok@emcraft.com>
      Reviewed-by: default avatarAndre Noll <maan@systemlinux.org>
      Acked-by: default avatarMaciej Sosnowski <maciej.sosnowski@intel.com>
      Signed-off-by: default avatarDan Williams <dan.j.williams@intel.com>
      b2f46fd8
  2. Jun 03, 2009
    • Dan Williams's avatar
      async_xor: permit callers to pass in a 'dma/page scribble' region · 04ce9ab3
      Dan Williams authored
      
      async_xor() needs space to perform dma and page address conversions.  In
      most cases the code can simply reuse the struct page * array because the
      size of the native pointer matches the size of a dma/page address.  In
      order to support archs where sizeof(dma_addr_t) is larger than
      sizeof(struct page *), or to preserve the input parameters, we utilize a
      memory region passed in by the caller.
      
      Since the code is now prepared to handle the case where it cannot
      perform address conversions on the stack, we no longer need the
      !HIGHMEM64G dependency in drivers/dma/Kconfig.
      
      [ Impact: don't clobber input buffers for address conversions ]
      
      Reviewed-by: default avatarAndre Noll <maan@systemlinux.org>
      Acked-by: default avatarMaciej Sosnowski <maciej.sosnowski@intel.com>
      Signed-off-by: default avatarDan Williams <dan.j.williams@intel.com>
      04ce9ab3
    • Dan Williams's avatar
      async_tx: structify submission arguments, add scribble · a08abd8c
      Dan Williams authored
      
      Prepare the api for the arrival of a new parameter, 'scribble'.  This
      will allow callers to identify scratchpad memory for dma address or page
      address conversions.  As this adds yet another parameter, take this
      opportunity to convert the common submission parameters (flags,
      dependency, callback, and callback argument) into an object that is
      passed by reference.
      
      Also, take this opportunity to fix up the kerneldoc and add notes about
      the relevant ASYNC_TX_* flags for each routine.
      
      [ Impact: moves api pass-by-value parameters to a pass-by-reference struct ]
      
      Signed-off-by: default avatarAndre Noll <maan@systemlinux.org>
      Acked-by: default avatarMaciej Sosnowski <maciej.sosnowski@intel.com>
      Signed-off-by: default avatarDan Williams <dan.j.williams@intel.com>
      a08abd8c
    • Dan Williams's avatar
      async_tx: kill ASYNC_TX_DEP_ACK flag · 88ba2aa5
      Dan Williams authored
      
      In support of inter-channel chaining async_tx utilizes an ack flag to
      gate whether a dependent operation can be chained to another.  While the
      flag is not set the chain can be considered open for appending.  Setting
      the ack flag closes the chain and flags the descriptor for garbage
      collection.  The ASYNC_TX_DEP_ACK flag essentially means "close the
      chain after adding this dependency".  Since each operation can only have
      one child the api now implicitly sets the ack flag at dependency
      submission time.  This removes an unnecessary management burden from
      clients of the api.
      
      [ Impact: clean up and enforce one dependency per operation ]
      
      Reviewed-by: default avatarAndre Noll <maan@systemlinux.org>
      Acked-by: default avatarMaciej Sosnowski <maciej.sosnowski@intel.com>
      Signed-off-by: default avatarDan Williams <dan.j.williams@intel.com>
      88ba2aa5
  3. Apr 08, 2009
  4. Jan 05, 2009
    • Dan Williams's avatar
      async_tx, dmaengine: document channel allocation and api rework · 28405d8d
      Dan Williams authored
      
      "Wouldn't it be better if the dmaengine layer made sure it didn't pass
      the same channel several times to a client?
      
      I mean, you seem concerned that the memcpy() API should be transparent
      and easy to use, but the whole registration interface is just
      ridiculously complicated..."
      	- Haavard
      
      The dmaengine and async_tx registration/allocation interface is indeed
      needlessly complicated.  This redesign has the following goals:
      
      1/ Simplify reference counting: dma channels are not something one would
         expect to be hotplugged, it should be an exceptional event handled by
         drivers not something clients should be mandated to handle in a
         callback.  The common case channel removal event is 'rmmod <dma driver>',
         which for simplicity should be disallowed if the channel is in use.
      2/ Add an interface for requesting exclusive access to a channel
         suitable to device-to-memory users.
      3/ Convert all memory-to-memory users over to a common allocator, the goal
         here is to not have competing channel allocation schemes.  The only
         competition should be between device-to-memory exclusive allocations and
         the memory-to-memory usage case where channels are shared between
         multiple "clients".
      
      Cc: Haavard Skinnemoen <haavard.skinnemoen@atmel.com>
      Cc: Neil Brown <neilb@suse.de>
      Cc: Jeff Garzik <jeff@garzik.org>
      Reviewed-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarDan Williams <dan.j.williams@intel.com>
      
      28405d8d
  5. Jan 10, 2008
    • Herbert Xu's avatar
      [CRYPTO] doc: Update api-intro.txt · 86f578de
      Herbert Xu authored
      
      This patch updates the list of transforms we support and clarifies that
      the Block Ciphers interface in fact supports all ciphers including stream
      ciphers.
      
      It also removes the obsolete Configuration Notes section and adds the
      linux-crypto mailing list as the primary bug reporting address.
      
      Finally it documents the fact that setkey should only be called from
      user context.
      
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      86f578de
  6. Sep 24, 2007
  7. May 09, 2007
  8. Mar 20, 2007
    • Johannes Schlumberger's avatar
      [CRYPTO] doc: Fix typo in hash example · 58e40308
      Johannes Schlumberger authored
      
      there is a tiny bug in Documentation/crypto/api-intro.txt.
      The file has the following example code:
      
      struct scatterlist sg[2];
      [...]
      if (crypto_hash_digest(&desc, &sg, 2, result))
      
      which does not match the declaration of crypto_hash_digest() in
      include/linux/crypto.h.
      
      (static inline int crypto_hash_digest(struct hash_desc *desc,
      	struct scatterlist *sg, unsigned int nbytes, u8 *out)
      
      The code in the example passes the address of a pointer (an array actually) as
      the second argument, while the function expects the pointer itself.
      
      I have attached a patch to fix this.
      
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      58e40308
  9. Feb 06, 2007
  10. Sep 20, 2006
  11. Sep 10, 2005
  12. Sep 01, 2005
  13. Apr 16, 2005
    • Linus Torvalds's avatar
      Linux-2.6.12-rc2 · 1da177e4
      Linus Torvalds authored
      Initial git repository build. I'm not bothering with the full history,
      even though we have it. We can create a separate "historical" git
      archive of that later if we want to, and in the meantime it's about
      3.2GB when imported into git - space that would just make the early
      git days unnecessarily complicated, when we don't have a lot of good
      infrastructure for it.
      
      Let it rip!
Loading