Commit 0918f18c ("crypto: s5p - add AES support for Exynos5433")
introduced bug in dereferencing clk_names[1] on platforms different from
Exynos5433. On Exynos board XU3 call trace is:

"Unable to handle kernel paging request at virtual address 00004000"
(strcmp) from [<c0774014>] (of_property_match_string+0x58/0xd0)
...
(devm_clk_get) from [<c075c248>] (s5p_aes_probe+0xd4/0x4a0)
(s5p_aes_probe) from [<c059dbc4>] (platform_drv_probe+0x6c/0xa4)

Fix this by setting array clk_names size to 2.

Fixes: 0918f18c ("crypto: s5p - add AES support for Exynos5433")
Reported-by: NKrzysztof Kozlowski <krzk@kernel.org>
Signed-off-by: NKamil Konieczny <k.konieczny@partner.samsung.com>
Reviewed-by: NKrzysztof Kozlowski <krzk@kernel.org>
Tested-by: NKrzysztof Kozlowski <krzk@kernel.org>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

Add AES crypto HW acceleration for Exynos5433, with the help of SlimSSS IP.
Reviewed-by: NKrzysztof Kozlowski <krzk@kernel.org>
Signed-off-by: NKamil Konieczny <k.konieczny@partner.samsung.com>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

Fix bug "s5p-sss crypto driver doesn't set next AES-CBC IV". While at this,
fix also AES-CTR mode. Tested on Odroid U3 with Eric Biggers branch
"iv-out-testing".
Signed-off-by: NKamil Konieczny <k.konieczny@partner.samsung.com>
Reported-by: NEric Biggers <ebiggers@kernel.org>
Reviewed-by: NKrzysztof Kozlowski <krzk@kernel.org>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

Replace hard coded AES block size with define.
Signed-off-by: NKrzysztof Kozlowski <krzk@kernel.org>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

Add support for aes counter(ctr) block cipher mode of operation for
Exynos Hardware. In contrast to ecb and cbc modes, aes-ctr allows
encyption/decryption for request sizes not being a multiple of 16(bytes).

Hardware requires block sizes being a multiple of 16(bytes). In order to
achieve this, copy request source and destination memory, and align it's size
to 16. That way hardware processes additional bytes, that are omitted
when copying the result back to its original destination.

Tested on Odroid-U3 with Exynos 4412 CPU, kernel 4.19-rc2 with crypto
run-time self test testmgr.
Signed-off-by: NChristoph Manszewski <c.manszewski@samsung.com>
Reviewed-by: NKrzysztof Kozlowski <krzk@kernel.org>
Acked-by: NKamil Konieczny <k.konieczny@partner.samsung.com>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

Modifications in s5p-sss.c:
- remove unnecessary 'goto' statements (making code shorter),
- change uint_8 and uint_32 to u8 and u32 types (for consistency in the
driver and making code shorter),
Signed-off-by: NChristoph Manszewski <c.manszewski@samsung.com>
Reviewed-by: NKrzysztof Kozlowski <krzk@kernel.org>
Acked-by: NKamil Konieczny <k.konieczny@partner.samsung.com>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

Fix misalignment of continued argument list.
Signed-off-by: NChristoph Manszewski <c.manszewski@samsung.com>
Reviewed-by: NKrzysztof Kozlowski <krzk@kernel.org>
Acked-by: NKamil Konieczny <k.konieczny@partner.samsung.com>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

Remove a race condition introduced by error path in functions:
s5p_aes_interrupt and s5p_aes_crypt_start. Setting the busy field of
struct s5p_aes_dev to false made it possible for s5p_tasklet_cb to
change the req field, before s5p_aes_complete was called.

Change the first parameter of s5p_aes_complete to struct
ablkcipher_request. Before spin_unlock, make a copy of the currently
handled request, to ensure s5p_aes_complete function call with the
correct request.
Signed-off-by: NChristoph Manszewski <c.manszewski@samsung.com>
Acked-by: NKamil Konieczny <k.konieczny@partner.samsung.com>
Reviewed-by: NKrzysztof Kozlowski <krzk@kernel.org>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

Many ahash algorithms set .cra_flags = CRYPTO_ALG_TYPE_AHASH.  But this
is redundant with the C structure type ('struct ahash_alg'), and
crypto_register_ahash() already sets the type flag automatically,
clearing any type flag that was already there.  Apparently the useless
assignment has just been copy+pasted around.

So, remove the useless assignment from all the ahash algorithms.

This patch shouldn't change any actual behavior.
Signed-off-by: NEric Biggers <ebiggers@google.com>
Acked-by: NGilad Ben-Yossef <gilad@benyossef.com>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

Improve the code (safety and readability) by indicating that data passed
through pointer is not modified.  This adds const keyword in many places,
most notably:
 - the driver data (pointer to struct samsung_aes_variant),
 - scatterlist addresses written as value to device registers,
 - key and IV arrays.
Signed-off-by: NKrzysztof Kozlowski <krzk@kernel.org>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

ahash_request 'req' argument passed by the caller
s5p_hash_handle_queue() cannot be NULL here because it is obtained from
non-NULL pointer via container_of().

This fixes smatch warning:
    drivers/crypto/s5p-sss.c:1213 s5p_hash_prepare_request() warn: variable dereferenced before check 'req' (see line 1208)
Signed-off-by: NKrzysztof Kozlowski <krzk@kernel.org>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

In AES-ECB mode crypt is done with key only, so any use of IV
can cause kernel Oops. Use IV only in AES-CBC and AES-CTR.
Signed-off-by: NKamil Konieczny <k.konieczny@partner.samsung.com>
Reported-by: NAnand Moon <linux.amoon@gmail.com>
Reviewed-by: NKrzysztof Kozlowski <krzk@kernel.org>
Tested-by: NAnand Moon <linux.amoon@gmail.com>
Cc: stable@vger.kernel.org # can be applied after commit 8f9702aaSigned-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

Replace GPL license statement with SPDX GPL-2.0 license identifier.
Signed-off-by: NKrzysztof Kozlowski <krzk@kernel.org>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

This code seems correct, but the goto was indented too far.
Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com>
Reviewed-by: NKrzysztof Kozlowski <krzk@kernel.org>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

Add support for MD5, SHA1, SHA256 hash algorithms for Exynos HW.
It uses the crypto framework asynchronous hash api.
It is based on omap-sham.c driver.
S5P has some HW differencies and is not implemented.

Modifications in s5p-sss:

- Add hash supporting structures and functions.

- Modify irq handler to handle both aes and hash signals.

- Resize resource end in probe if EXYNOS_HASH is enabled in
  Kconfig.

- Add new copyright line and new author.

- Tested on Odroid-U3 with Exynos 4412 CPU, kernel 4.13-rc6
  with crypto run-time self test testmgr
  and with tcrypt module with: modprobe tcrypt sec=1 mode=N
  where N=402, 403, 404 (MD5, SHA1, SHA256).

Modifications in drivers/crypto/Kconfig:

- Add new CRYPTO_DEV_EXYNOS_HASH, depend on !EXYNOS_RNG
  and CRYPTO_DEV_S5P

- Select sw algorithms MD5, SHA1 and SHA256 in EXYNOS_HASH
  as they are needed for fallback.
Acked-by: NVladimir Zapolskiy <vz@mleia.com>
Reviewed-by: NKrzysztof Kozlowski <krzk@kernel.org>
Signed-off-by: NKamil Konieczny <k.konieczny@partner.samsung.com>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

Change #define lines to use tabs consistently.
Acked-by: NVladimir Zapolskiy <vz@mleia.com>
Reviewed-by: NKrzysztof Kozlowski <krzk@kernel.org>
Signed-off-by: NKamil Konieczny <k.konieczny@partner.samsung.com>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

Add kernel-doc to s5p_aes_dev structure.
Signed-off-by: NKrzysztof Kozlowski <krzk@kernel.org>
Reviewed-by: NBartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

The driver uses type of device (variant) only during probe so there is
no need to store it for later.
Signed-off-by: NKrzysztof Kozlowski <krzk@kernel.org>
Reviewed-by: NBartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

Driver is capable of handling only one request at a time and it stores
it in its state container struct s5p_aes_dev.  This stored request must be
protected between concurrent invocations (e.g. completing current
request and scheduling new one).  Combination of lock and "busy" field
is used for that purpose.

When "busy" field is true, the driver will not accept new request thus
it will not overwrite currently handled data.

However commit 28b62b14 ("crypto: s5p-sss - Fix spinlock recursion
on LRW(AES)") moved some of the write to "busy" field out of a lock
protected critical section.  This might lead to potential race between
completing current request and scheduling a new one.  Effectively the
request completion might try to operate on new crypto request.

Cc: <stable@vger.kernel.org> # v4.10.x
Fixes: 28b62b14 ("crypto: s5p-sss - Fix spinlock recursion on LRW(AES)")
Signed-off-by: NKrzysztof Kozlowski <krzk@kernel.org>
Reviewed-by: NBartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

Running TCRYPT with LRW compiled causes spinlock recursion:

    testing speed of async lrw(aes) (lrw(ecb-aes-s5p)) encryption
    tcrypt: test 0 (256 bit key, 16 byte blocks): 19007 operations in 1 seconds (304112 bytes)
    tcrypt: test 1 (256 bit key, 64 byte blocks): 15753 operations in 1 seconds (1008192 bytes)
    tcrypt: test 2 (256 bit key, 256 byte blocks): 14293 operations in 1 seconds (3659008 bytes)
    tcrypt: test 3 (256 bit key, 1024 byte blocks): 11906 operations in 1 seconds (12191744 bytes)
    tcrypt: test 4 (256 bit key, 8192 byte blocks):
    BUG: spinlock recursion on CPU#1, irq/84-10830000/89
     lock: 0xeea99a68, .magic: dead4ead, .owner: irq/84-10830000/89, .owner_cpu: 1
    CPU: 1 PID: 89 Comm: irq/84-10830000 Not tainted 4.11.0-rc1-00001-g897ca6d0800d #559
    Hardware name: SAMSUNG EXYNOS (Flattened Device Tree)
    [<c010e1ec>] (unwind_backtrace) from [<c010ae1c>] (show_stack+0x10/0x14)
    [<c010ae1c>] (show_stack) from [<c03449c0>] (dump_stack+0x78/0x8c)
    [<c03449c0>] (dump_stack) from [<c015de68>] (do_raw_spin_lock+0x11c/0x120)
    [<c015de68>] (do_raw_spin_lock) from [<c0720110>] (_raw_spin_lock_irqsave+0x20/0x28)
    [<c0720110>] (_raw_spin_lock_irqsave) from [<c0572ca0>] (s5p_aes_crypt+0x2c/0xb4)
    [<c0572ca0>] (s5p_aes_crypt) from [<bf1d8aa4>] (do_encrypt+0x78/0xb0 [lrw])
    [<bf1d8aa4>] (do_encrypt [lrw]) from [<bf1d8b00>] (encrypt_done+0x24/0x54 [lrw])
    [<bf1d8b00>] (encrypt_done [lrw]) from [<c05732a0>] (s5p_aes_complete+0x60/0xcc)
    [<c05732a0>] (s5p_aes_complete) from [<c0573440>] (s5p_aes_interrupt+0x134/0x1a0)
    [<c0573440>] (s5p_aes_interrupt) from [<c01667c4>] (irq_thread_fn+0x1c/0x54)
    [<c01667c4>] (irq_thread_fn) from [<c0166a98>] (irq_thread+0x12c/0x1e0)
    [<c0166a98>] (irq_thread) from [<c0136a28>] (kthread+0x108/0x138)
    [<c0136a28>] (kthread) from [<c0107778>] (ret_from_fork+0x14/0x3c)

Interrupt handling routine was calling req->base.complete() under
spinlock.  In most cases this wasn't fatal but when combined with some
of the cipher modes (like LRW) this caused recursion - starting the new
encryption (s5p_aes_crypt()) while still holding the spinlock from
previous round (s5p_aes_complete()).

Beside that, the s5p_aes_interrupt() error handling path could execute
two completions in case of error for RX and TX blocks.

Rewrite the interrupt handling routine and the completion by:

1. Splitting the operations on scatterlist copies from
   s5p_aes_complete() into separate s5p_sg_done(). This still should be
   done under lock.
   The s5p_aes_complete() now only calls req->base.complete() and it has
   to be called outside of lock.

2. Moving the s5p_aes_complete() out of spinlock critical sections.
   In interrupt service routine s5p_aes_interrupts(), it appeared in few
   places, including error paths inside other functions called from ISR.
   This code was not so obvious to read so simplify it by putting the
   s5p_aes_complete() only within ISR level.
Reported-by: NNathan Royce <nroycea+kernel@gmail.com>
Cc: <stable@vger.kernel.org> # v4.10.x: 07de4bc8 crypto: s5p-sss - Fix completing
Cc: <stable@vger.kernel.org> # v4.10.x
Signed-off-by: NKrzysztof Kozlowski <krzk@kernel.org>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

In a regular interrupt handler driver was finishing the crypt/decrypt
request by calling complete on crypto request.  This is disallowed since
converting to skcipher in commit b286d8b1 ("crypto: skcipher - Add
skcipher walk interface") and causes a warning:
	WARNING: CPU: 0 PID: 0 at crypto/skcipher.c:430 skcipher_walk_first+0x13c/0x14c

The interrupt is marked shared but in fact there are no other users
sharing it.  Thus the simplest solution seems to be to just use a
threaded interrupt handler, after converting it to oneshot.
Signed-off-by: NKrzysztof Kozlowski <krzk@kernel.org>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

Bring some consistency by:
1. Replacing fixed-space indentation of structure members with just
   tabs.
2. Remove indentation in declaration of local variable between type and
   name.  Driver was mixing usage of such indentation and lack of it.
   When removing indentation, reorder variables in
   reversed-christmas-tree order with first variables being initialized
   ones.
Signed-off-by: NKrzysztof Kozlowski <k.kozlowski@samsung.com>
Acked-by: NVladimir Zapolskiy <vz@mleia.com>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

sg_dma_len() macro can be used only on scattelists which are mapped, so
all calls to it before dma_map_sg() are invalid. Replace them by proper
check for direct sg segment length read.

Fixes: a49e490c ("crypto: s5p-sss - add S5PV210 advanced crypto engine support")
Fixes: 9e4a1100 ("crypto: s5p-sss - Handle unaligned buffers")
Signed-off-by: NMarek Szyprowski <m.szyprowski@samsung.com>
Reviewed-by: NKrzysztof Kozlowski <k.kozlowski@samsung.com>
Acked-by: NVladimir Zapolskiy <vz@mleia.com>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

The tcrypt testing module on Exynos5422-based Odroid XU3/4 board failed on
testing 8 kB size blocks:

	$ sudo modprobe tcrypt sec=1 mode=500
	testing speed of async ecb(aes) (ecb-aes-s5p) encryption
	test 0 (128 bit key, 16 byte blocks): 21971 operations in 1 seconds (351536 bytes)
	test 1 (128 bit key, 64 byte blocks): 21731 operations in 1 seconds (1390784 bytes)
	test 2 (128 bit key, 256 byte blocks): 21932 operations in 1 seconds (5614592 bytes)
	test 3 (128 bit key, 1024 byte blocks): 21685 operations in 1 seconds (22205440 bytes)
	test 4 (128 bit key, 8192 byte blocks):

This was caused by a race issue of missed BRDMA_DONE ("Block cipher
Receiving DMA") interrupt. Device starts processing the data in DMA mode
immediately after setting length of DMA block: receiving (FCBRDMAL) or
transmitting (FCBTDMAL). The driver sets these lengths from interrupt
handler through s5p_set_dma_indata() function (or xxx_setdata()).

However the interrupt handler was first dealing with receive buffer
(dma-unmap old, dma-map new, set receive block length which starts the
operation), then with transmit buffer and finally was clearing pending
interrupts (FCINTPEND). Because of the time window between setting
receive buffer length and clearing pending interrupts, the operation on
receive buffer could end already and driver would miss new interrupt.

User manual for Exynos5422 confirms in example code that setting DMA
block lengths should be the last operation.

The tcrypt hang could be also observed in following blocked-task dmesg:

INFO: task modprobe:258 blocked for more than 120 seconds.
      Not tainted 4.6.0-rc4-next-20160419-00005-g9eac8b7b7753-dirty #42
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
modprobe        D c06b09d8     0   258    256 0x00000000
[<c06b09d8>] (__schedule) from [<c06b0f24>] (schedule+0x40/0xac)
[<c06b0f24>] (schedule) from [<c06b49f8>] (schedule_timeout+0x124/0x178)
[<c06b49f8>] (schedule_timeout) from [<c06b17fc>] (wait_for_common+0xb8/0x144)
[<c06b17fc>] (wait_for_common) from [<bf0013b8>] (test_acipher_speed+0x49c/0x740 [tcrypt])
[<bf0013b8>] (test_acipher_speed [tcrypt]) from [<bf003e8c>] (do_test+0x2240/0x30ec [tcrypt])
[<bf003e8c>] (do_test [tcrypt]) from [<bf008048>] (tcrypt_mod_init+0x48/0xa4 [tcrypt])
[<bf008048>] (tcrypt_mod_init [tcrypt]) from [<c010177c>] (do_one_initcall+0x3c/0x16c)
[<c010177c>] (do_one_initcall) from [<c0191ff0>] (do_init_module+0x5c/0x1ac)
[<c0191ff0>] (do_init_module) from [<c0185610>] (load_module+0x1a30/0x1d08)
[<c0185610>] (load_module) from [<c0185ab0>] (SyS_finit_module+0x8c/0x98)
[<c0185ab0>] (SyS_finit_module) from [<c01078c0>] (ret_fast_syscall+0x0/0x3c)

Fixes: a49e490c ("crypto: s5p-sss - add S5PV210 advanced crypto engine support")
Cc: <stable@vger.kernel.org>
Signed-off-by: NKrzysztof Kozlowski <k.kozlowski@samsung.com>
Tested-by: NMarek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

The BIT() macro is obvious and well known, so prefer to use it instead
of crafted own macro.
Signed-off-by: NKrzysztof Kozlowski <k.kozlowski@samsung.com>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

Beside regular feed control interrupt, the driver requires also hash
interrupt for older SoCs (samsung,s5pv210-secss). However after
requesting it, the interrupt handler isn't doing anything with it, not
even clearing the hash interrupt bit.

Driver does not provide hash functions so it is safe to remove the hash
interrupt related code and to not require the interrupt in Device Tree.
Signed-off-by: NKrzysztof Kozlowski <k.kozlowski@samsung.com>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

The driver makes copies of memory (input or output scatterlists) if they
are not aligned. In s5p_aes_crypt_start() error path (on unsuccessful
initialization of output scatterlist), if input scatterlist was not
aligned, the driver first freed copied input memory and then unmapped it
from the device, instead of doing otherwise (unmap and then free).

This was wrong in two ways:
1. Freed pages were still mapped to the device.
2. The dma_unmap_sg() iterated over freed scatterlist structure.

The call to s5p_free_sg_cpy() in this error path is not needed because
the copied scatterlists will be freed by s5p_aes_complete().

Fixes: 9e4a1100 ("crypto: s5p-sss - Handle unaligned buffers")
Signed-off-by: NKrzysztof Kozlowski <k.kozlowski@samsung.com>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

Sort the headers alphabetically to improve readability and to spot
duplications easier.
Suggested-by: NVladimir Zapolskiy <vz@mleia.com>
Signed-off-by: NKrzysztof Kozlowski <k.kozlowski@samsung.com>
Acked-by: NVladimir Zapolskiy <vz@mleia.com>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

During crypto selftests on Odroid XU3 (Exynos5422) some of the
algorithms failed because of passing AES-block unaligned source and
destination buffers:

alg: skcipher: encryption failed on chunk test 1 for ecb-aes-s5p: ret=22

Handle such case by copying the buffers to a new aligned and contiguous
space.
Signed-off-by: NKrzysztof Kozlowski <krzk@kernel.org>
Acked-by: NVladimir Zapolskiy <vz@mleia.com>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

Remove unneeded inclusion of delay.h and get rid of indentation from
labels.
Signed-off-by: NKrzysztof Kozlowski <krzk@kernel.org>
Acked-by: NVladimir Zapolskiy <vz@mleia.com>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

Use memcpy_toio to fix following sparse warning:

drivers/crypto/s5p-sss.c:386:40: warning: incorrect type in argument 1 (different address spaces)
drivers/crypto/s5p-sss.c:386:40:    expected void *<noident>
drivers/crypto/s5p-sss.c:386:40:    got void [noderef] <asn:2>*
Signed-off-by: NKrzysztof Kozlowski <k.kozlowski.k@gmail.com>
Acked-by: NVladimir Zapolskiy <vz@mleia.com>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

Improve a little bit code readability and use dev_info/err for printing
messages.
Signed-off-by: NKrzysztof Kozlowski <k.kozlowski.k@gmail.com>
Acked-by: NVladimir Zapolskiy <vz@mleia.com>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

A platform_driver does not need to set an owner, it will be populated by the
driver core.
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

As we are preparing to enable multiplatform support on EXYNOS,
we can no longer include mach/*.h or plat/*.h headers from device
drivers.

The s5p-sss driver was just enabled for EXYNOS when it used to
be used only on s5pv210, and it includes two samsung platform
specific header files for historic reasons. Fortunately, it no
longer actually needs them, so we can remove the #includes and
avoid the problem
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
Cc: Naveen Krishna Chatradhi <ch.naveen@samsung.com>
Cc: Tomasz Figa <t.figa@samsung.com>
Cc: <linux-samsung-soc@vger.kernel.org>
Cc: Vladimir Zapolskiy <vz@mleia.com>
Reviewed-by: NJingoo Han <jg1.han@samsung.com>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

Currently, the driver enqueues a request only if the busy bit is
false. And every request initiates a dequeue. If 2 requests arrive
simultaneously, only one of them will be dequeued.

To avoid this senario, we will enqueue the next request irrespective
of the system condition (that is what queue is here for). Also
schedule at a tasklet immediatly after the current request is done.
The tasklet will dequeue the next request in the queue, giving
continuous loop. tasklet will exit if there are no requests in the
queue.
Signed-off-by: NNaveen Krishna Chatradhi <ch.naveen@samsung.com>
CC: David S. Miller <davem@davemloft.net>
CC: <linux-samsung-soc@vger.kernel.org>
Acked-by: NVladimir Zapolskiy <vz@mleia.com>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

This patch set adds use of clk_prepare/clk_unprepare as
required by generic clock framework.
Signed-off-by: NNaveen Krishna Chatradhi <ch.naveen@samsung.com>
Reviewed-by: NTomasz Figa <t.figa@samsung.com>
CC: David S. Miller <davem@davemloft.net>
CC: <linux-samsung-soc@vger.kernel.org>
Acked-by: NVladimir Zapolskiy <vz@mleia.com>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

This patch adds code to validate "iv" buffer before trying to
memcpy the contents
Signed-off-by: NNaveen Krishna Chatradhi <ch.naveen@samsung.com>
Reviewed-by: NTomasz Figa <t.figa@samsung.com>
CC: David S. Miller <davem@davemloft.net>
CC: <linux-samsung-soc@vger.kernel.org>
Acked-by: NVladimir Zapolskiy <vz@mleia.com>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

This patch adds new compatible and variant struct to support the SSS
module on Exynos4 (Exynos4210), Exynos5 (Exynos5420 and Exynos5250)
for which
1. AES register are at an offset of 0x200 and
2. hash interrupt is not available
Signed-off-by: NNaveen Krishna Chatradhi <ch.naveen@samsung.com>
Reviewed-by: NTomasz Figa <t.figa@samsung.com>
CC: David S. Miller <davem@davemloft.net>
CC: <linux-samsung-soc@vger.kernel.org>
Acked-by: NVladimir Zapolskiy <vz@mleia.com>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

This patch adds device tree support to the s5p-sss.c crypto driver.
Signed-off-by: NNaveen Krishna Chatradhi <ch.naveen@samsung.com>
CC: David S. Miller <davem@davemloft.net>
CC: <linux-samsung-soc@vger.kernel.org>
Acked-by: NVladimir Zapolskiy <vz@mleia.com>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

This patch uses the platform_get_irq() instead of the
platform_get_irq_byname(). Making feeder control interrupt
as resource "0" and hash interrupt as "1".

reasons for this change.
1. Cannot find any Arch which is currently using this driver
2. Samsung Exynos4 and 5 SoCs only use the feeder control interrupt
3. Patches adding support for DT and H/W version are in pipeline
Signed-off-by: NNaveen Krishna Chatradhi <ch.naveen@samsung.com>
Reviewed-by: NTomasz Figa <t.figa@samsung.com>
CC: David S. Miller <davem@davemloft.net>
CC: <linux-samsung-soc@vger.kernel.org>
Acked-by: NVladimir Zapolskiy <vz@mleia.com>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>