03 Jul, 2019

2 commits


30 May, 2019

4 commits


12 Oct, 2017

3 commits

  • SEC1 doesn't support S/G in descriptors so for hash operations,
    the CPU has to build a buffer containing the buffered block and
    the incoming data. This generates a lot of memory copies which
    represents more than 50% of CPU time of a md5sum operation as
    shown below with a 'perf record'.

    |--86.24%-- kcapi_md_digest
    | |
    | |--86.18%-- _kcapi_common_vmsplice_chunk_fd
    | | |
    | | |--83.68%-- splice
    | | | |
    | | | |--83.59%-- ret_from_syscall
    | | | | |
    | | | | |--83.52%-- sys_splice
    | | | | | |
    | | | | | |--83.49%-- splice_from_pipe
    | | | | | | |
    | | | | | | |--83.04%-- __splice_from_pipe
    | | | | | | | |
    | | | | | | | |--80.67%-- pipe_to_sendpage
    | | | | | | | | |
    | | | | | | | | |--78.25%-- hash_sendpage
    | | | | | | | | | |
    | | | | | | | | | |--60.08%-- ahash_process_req
    | | | | | | | | | | |
    | | | | | | | | | | |--56.36%-- sg_copy_buffer
    | | | | | | | | | | | |
    | | | | | | | | | | | |--55.29%-- memcpy
    | | | | | | | | | | | |

    However, unlike SEC2+, SEC1 offers the possibility to chain
    descriptors. It is therefore possible to build a first descriptor
    pointing to the buffered data and a second descriptor pointing to
    the incoming data, hence avoiding the memory copy to a single
    buffer.

    With this patch, the time necessary for a md5sum on a 90Mbytes file
    is approximately 3 seconds. Without the patch it takes 6 seconds.

    Signed-off-by: Christophe Leroy
    Signed-off-by: Herbert Xu

    LEROY Christophe
     
  • The number of channels is known from the beginning, no need to
    test it everytime.
    This patch defines two additional done functions handling only channel 0.
    Then the probe registers the correct one based on the number of channels.

    Signed-off-by: Christophe Leroy
    Signed-off-by: Herbert Xu

    LEROY Christophe
     
  • This patch zeroize the descriptor at allocation using memset().
    This has two advantages:
    - It reduces the number of places where data has to be set to 0
    - It avoids reading memory and loading the cache with data that
    will be entirely replaced.

    Signed-off-by: Christophe Leroy
    Signed-off-by: Herbert Xu

    LEROY Christophe
     

04 Dec, 2015

1 commit


10 Aug, 2015

1 commit

  • The probe error path for this driver, for all intents and purposes,
    is the talitos_remove() function due to the common "goto err_out".

    Without this patch applied, talitos_remove() will panic under these
    two conditions:

    1. If the RNG device hasn't been registered via
    talitos_register_rng() prior to entry into talitos_remove(),
    then the attempt to unregister the RNG "device" will cause a panic.

    2. If the priv->chan array has not been allocated prior to entry
    into talitos_remove(), then the per-channel FIFO cleanup will panic
    because of the dereference of that NULL "array".

    Both of the above scenarios occur if talitos_probe_irq() fails.

    This patch resolves issue #1 by introducing a boolean to mask the
    hwrng_unregister() call in talitos_unregister_rng() if RNG device
    registration was unsuccessful.

    It resolves issue #2 by checking that priv->chan is not NULL in the
    per-channel FIFO cleanup for loop.

    Signed-off-by: Aaron Sierra
    Signed-off-by: Herbert Xu

    Aaron Sierra
     

04 Aug, 2015

1 commit

  • Compiling the talitos driver with my GCC 4.3.1 e500v2 cross-compiler
    resulted in a failed build due to the anonymous union/structures
    introduced in this commit:

    crypto: talitos - enhanced talitos_desc struct for SEC1

    The build error was:

    drivers/crypto/talitos.h:56: error: unknown field 'len' specified in initializer
    drivers/crypto/talitos.h:56: warning: missing braces around initializer
    drivers/crypto/talitos.h:56: warning: (near initialization for 'zero_entry.')
    drivers/crypto/talitos.h:57: error: unknown field 'j_extent' specified in initializer
    drivers/crypto/talitos.h:58: error: unknown field 'eptr' specified in initializer
    drivers/crypto/talitos.h:58: warning: excess elements in struct initializer
    drivers/crypto/talitos.h:58: warning: (near initialization for 'zero_entry')
    make[2]: *** [drivers/crypto/talitos.o] Error 1
    make[1]: *** [drivers/crypto] Error 2
    make: *** [drivers] Error 2

    This patch eliminates the errors by relying on the C standard's
    implicit assignment of zero to static variables.

    Signed-off-by: Aaron Sierra
    Signed-off-by: Herbert Xu

    Aaron Sierra
     

21 Apr, 2015

6 commits

  • SEC1 doesn't support scatter/gather, SEC1 doesn't handle link tables.
    Therefore, for SEC1 we have to do it by SW. For that, we reserve
    space at the end of the extended descriptor, in lieu of the space
    reserved for the link tables on SEC2, and we perform sg_copy() when
    preparing the descriptors

    We also adapt the max buffer size which is only 32k on SEC1 while it
    is 64k on SEC2+

    Signed-off-by: Christophe Leroy
    Signed-off-by: Herbert Xu

    LEROY Christophe
     
  • This patch adapts the interrupts handling and reset function for
    SEC1. On SEC1, registers are almost similar to SEC2+, but bits
    are sometimes located at different places. So we need to define
    TALITOS1 and TALITOS2 versions of some fields, and manage according
    to whether it is SEC1 or SEC2.

    On SEC1, only one interrupt vector is dedicated to the SEC, so only
    interrupt_4ch is needed.

    On SEC1, interrupts are enabled by clearing related bits in IMR,
    while on SEC2, interrupts are enabled by seting the bits in IMR.

    SEC1 also performs parity verification in the DES Unit. We have
    to disable this feature because the test vectors provided in
    the kernel have parity errors.

    In reset functions, only SEC2 supports continuation after error.
    For SEC1, we have to reset in all cases.

    For errors handling, SEC2+ names have been kept, but displayed
    text have been amended to reflect exact meaning on SEC1.

    Signed-off-by: Christophe Leroy
    Signed-off-by: Herbert Xu

    LEROY Christophe
     
  • SEC 1.0, 1.2 and 2.x+ have different EU base addresses, so we need to
    define pointers for each EU in the driver private data structure.
    The proper address is set by the probe function depending on the
    SEC type, in order to provide access to the proper address.

    Signed-off-by: Christophe Leroy
    Signed-off-by: Herbert Xu

    LEROY Christophe
     
  • SEC1 descriptor is a bit different to SEC2+ descriptor.
    talitos_submit() will have to copy hdr field into hdr1 field and
    send the descriptor starting at hdr1 up to next_desc.
    For SEC2, it remains unchanged and next_desc is just ignored.

    Signed-off-by: Christophe Leroy
    Signed-off-by: Herbert Xu

    LEROY Christophe
     
  • We add a new feature in the features field, to mark compatible
    "fsl,sec1.0"
    We also define a helper function called has_ftr_sec1() to help
    functions quickly determine if they are running on SEC1 or SEC2+.
    When only SEC1 or SEC2 is compiled in, has_ftr_sec1() return
    trivial corresponding value. If both are compiled in, feature
    field is checked.

    Signed-off-by: Christophe Leroy
    Signed-off-by: Herbert Xu

    LEROY Christophe
     
  • This patch enhances the talitos_desc struct with fields for SEC1.
    SEC1 has only one header field, and has a 'next_desc' field in
    addition.
    This mixed descriptor will continue to fit SEC2, and for SEC1
    we will recopy hdr value into hdr1 value in talitos_submit()

    Signed-off-by: Christophe Leroy
    Signed-off-by: Herbert Xu

    LEROY Christophe
     

11 Jul, 2012

3 commits


21 Nov, 2011

2 commits

  • Some later SEC v3.x are equipped with a second IRQ line.
    By correctly assigning IRQ affinity, this feature can be
    used to increase performance on dual core parts, like the
    MPC8572E and P2020E.

    The existence of the 2nd IRQ is determined from the device
    node's interrupt property. If present, the driver remaps
    two of four channels, which in turn makes those channels
    trigger their interrupts on the 2nd line instead of the first.
    To handle single- and dual-IRQ combinations efficiently,
    talitos gets two new interrupt handlers and back-half workers.

    [includes a fix to MCR_LO's address.]

    Signed-off-by: Kim Phillips
    Signed-off-by: Herbert Xu

    Kim Phillips
     
  • Add a reg member to the channel struct and use it to
    access channels.

    Signed-off-by: Kim Phillips
    Signed-off-by: Herbert Xu

    Kim Phillips
     

19 May, 2010

2 commits

  • SEC h/w versions 2.1 and above support sha224 via explicit instruction.

    Performing sha224 ahashes on earlier versions is still possible because
    they support sha256 (sha224 is sha256 with different initial constants
    and a different truncation length). We do this by overriding hardware
    context self-initialization, and perform it manually in s/w instead.

    Thanks to Lee for his fixes for correct execution on actual sec2.0 h/w.

    Signed-off-by: Kim Phillips
    Signed-off by: Lee Nipper
    Signed-off-by: Herbert Xu

    Kim Phillips
     
  • Add the following alorithms to talitos:
    md5,
    sha1,
    sha256,
    sha384,
    sha512.
    These are all type ahash.

    Signed-off-by: Lee Nipper
    Acked-By: Kim Phillips
    Signed-off-by: Herbert Xu

    Lee Nipper
     

13 Aug, 2009

1 commit


25 Dec, 2008

3 commits

  • Base versions handle constant folding just fine.

    Signed-off-by: Harvey Harrison
    Signed-off-by: Herbert Xu

    Harvey Harrison
     
  • SEC version 2.1 and above adds the capability to do the IPSec ICV
    memcmp in h/w. Results of the cmp are written back in the descriptor
    header, along with the done status. A new callback is added that
    checks these ICCR bits instead of performing the memcmp on the core,
    and is enabled by h/w capability.

    Signed-off-by: Kim Phillips

    After testing on different parts, another condition was added
    before using h/w auth check because different
    SEC revisions require different handling.

    The SEC 3.0 allows a more flexible link table where
    the auth data can span separate link table entries.
    The SEC 2.4/2.1 does not support this case.
    So a test was added in the decrypt routine
    for a fragmented case; the h/w auth check is disallowed for
    revisions not having the extent in the link table;
    in this case the hw auth check is done by software.

    A portion of a previous change for SEC 3.0 link table handling
    was removed since it became dead code with the hw auth check supported.

    This seems to be the best compromise for using hw auth check
    on supporting SEC revisions; it keeps the link table logic
    simpler for the fragmented cases.

    Signed-off-by: Lee Nipper
    Signed-off-by: Herbert Xu

    Kim Phillips
     
  • In talitos_interrupt, upon one done interrupt, mask further done interrupts,
    and ack only any error interrupt.
    In talitos_done, unmask done interrupts after completing processing.
    In flush_channel, ack each done channel processed.
    Keep done overflow interrupts masked because even though each pkt
    is ack'ed, a few done overflows still occur.

    Signed-off-by: Lee Nipper
    Signed-off-by: Kim Phillips
    Signed-off-by: Herbert Xu

    Lee Nipper
     

10 Jul, 2008

2 commits