Currently find_zip_device() finds zip device which has the min NUMA
distance with current CPU.

This patch modifies find_zip_device to return sub-optimal device when best
device has no qps. This patch sorts all devices by NUMA distance, then
finds the best zip device which has free qp.
Signed-off-by: NZhou Wang <wangzhou1@hisilicon.com>
Signed-off-by: NShukun Tan <tanshukun1@huawei.com>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

Use sgl API to get sgl dma addr and len, this will help to avoid compile
error in some platforms. So NEED_SG_DMA_LENGTH can be removed here, which
can only be selected by arch code.
Signed-off-by: NZhou Wang <wangzhou1@hisilicon.com>
Suggested-by: NHerbert Xu <herbert@gondor.apana.org.au>
Acked-by: NArd Biesheuvel <ard.biesheuvel@linaro.org>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

Now that the blkcipher algorithm type has been removed in favor of
skcipher, rename the crypto_blkcipher kernel module to crypto_skcipher,
and rename the config options accordingly:

	CONFIG_CRYPTO_BLKCIPHER => CONFIG_CRYPTO_SKCIPHER
	CONFIG_CRYPTO_BLKCIPHER2 => CONFIG_CRYPTO_SKCIPHER2
Signed-off-by: NEric Biggers <ebiggers@google.com>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

Now that all "blkcipher" algorithms have been converted to "skcipher",
remove the blkcipher algorithm type.

The skcipher (symmetric key cipher) algorithm type was introduced a few
years ago to replace both blkcipher and ablkcipher (synchronous and
asynchronous block cipher).  The advantages of skcipher include:

  - A much less confusing name, since none of these algorithm types have
    ever actually been for raw block ciphers, but rather for all
    length-preserving encryption modes including block cipher modes of
    operation, stream ciphers, and other length-preserving modes.

  - It unified blkcipher and ablkcipher into a single algorithm type
    which supports both synchronous and asynchronous implementations.
    Note, blkcipher already operated only on scatterlists, so the fact
    that skcipher does too isn't a regression in functionality.

  - Better type safety by using struct skcipher_alg, struct
    crypto_skcipher, etc. instead of crypto_alg, crypto_tfm, etc.

  - It sometimes simplifies the implementations of algorithms.

Also, the blkcipher API was no longer being tested.
Signed-off-by: NEric Biggers <ebiggers@google.com>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

Now that the crypto_skcipher_type() function has been removed, there's
no reason to call the crypto_type struct for skciphers
"crypto_skcipher_type2".  Rename it to simply "crypto_skcipher_type".
Signed-off-by: NEric Biggers <ebiggers@google.com>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

crypto_has_ablkcipher() has no users, and it does the same thing as
crypto_has_skcipher() anyway.  So remove it.  This also removes the last
user of crypto_skcipher_type() and crypto_skcipher_mask(), so remove
those too.
Signed-off-by: NEric Biggers <ebiggers@google.com>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

crypto_has_skcipher() and crypto_has_skcipher2() do the same thing: they
check for the availability of an algorithm of type skcipher, blkcipher,
or ablkcipher, which also meets any non-type constraints the caller
specified.  And they have exactly the same prototype.

Therefore, eliminate the redundancy by removing crypto_has_skcipher()
and renaming crypto_has_skcipher2() to crypto_has_skcipher().
Signed-off-by: NEric Biggers <ebiggers@google.com>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

This patch adds documentation for Device-Tree bindings of the
Security System cryptographic offloader driver.
Signed-off-by: NCorentin Labbe <clabbe.montjoie@gmail.com>
Acked-by: NMaxime Ripard <mripard@kernel.org>
Reviewed-by: NRob Herring <robh@kernel.org>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

The Security System is an hardware cryptographic offloader present
on Allwinner SoCs A80 and A83T.
It is different from the previous sun4i-ss.

This driver supports AES cipher in CBC and ECB mode.
Acked-by: NMaxime Ripard <mripard@kernel.org>
Signed-off-by: NCorentin Labbe <clabbe.montjoie@gmail.com>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

Test vectors for blake2b with various digest sizes. As the algorithm is
the same up to the digest calculation, the key and input data length is
distributed in a way that tests all combinanions of the two over the
digest sizes.

Based on the suggestion from Eric, the following input sizes are tested
[0, 1, 7, 15, 64, 247, 256], where blake2b blocksize is 128, so the
padded and the non-padded input buffers are tested.

          blake2b-160  blake2b-256  blake2b-384  blake2b-512
         ---------------------------------------------------
len=0   | klen=0       klen=1       klen=32      klen=64
len=1   | klen=32      klen=64      klen=0       klen=1
len=7   | klen=64      klen=0       klen=1       klen=32
len=15  | klen=1       klen=32      klen=64      klen=0
len=64  | klen=0       klen=1       klen=32      klen=64
len=247 | klen=32      klen=64      klen=0       klen=1
len=256 | klen=64      klen=0       klen=1       klen=32

Where key:

- klen=0: empty key
- klen=1: 1 byte value 0x42, 'B'
- klen=32: first 32 bytes of the default key, sequence 00..1f
- klen=64: default key, sequence 00..3f

The unkeyed vectors are ordered before keyed, as this is required by
testmgr.

CC: Eric Biggers <ebiggers@kernel.org>
Signed-off-by: NDavid Sterba <dsterba@suse.com>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

The patch brings support of several BLAKE2 variants (2b with various
digest lengths).  The keyed digest is supported, using tfm->setkey call.
The in-tree user will be btrfs (for checksumming), we're going to use
the BLAKE2b-256 variant.

The code is reference implementation taken from the official sources and
modified in terms of kernel coding style (whitespace, comments, uintXX_t
-> uXX types, removed unused prototypes and #ifdefs, removed testing
code, changed secure_zero_memory -> memzero_explicit, used own helpers
for unaligned reads/writes and rotations).

Further changes removed sanity checks of key length or output size,
these values are verified in the crypto API callbacks or hardcoded in
shash_alg and not exposed to users.
Signed-off-by: NDavid Sterba <dsterba@suse.com>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

Since we have a dedicated Allwinner directory for crypto driver, move
the sun4i-ss driver in it.
Acked-by: NMaxime Ripard <mripard@kernel.org>
Signed-off-by: NCorentin Labbe <clabbe.montjoie@gmail.com>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

The Crypto Engine is an hardware cryptographic offloader present
on all recent Allwinner SoCs H2+, H3, R40, A64, H5, H6

This driver supports AES cipher in CBC/ECB mode.
Acked-by: NMaxime Ripard <mripard@kernel.org>
Signed-off-by: NCorentin Labbe <clabbe.montjoie@gmail.com>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

Since a second Allwinner crypto driver will be added, it is better to
create a dedicated subdirectory.
Acked-by: NMaxime Ripard <mripard@kernel.org>
Signed-off-by: NCorentin Labbe <clabbe.montjoie@gmail.com>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

Bitwise-or'ing 0xffffffff with the u32 variable ctr is the same result
as assigning the value to ctr.  Remove the redundant bitwise-or and
just use an assignment.

Addresses-Coverity: ("Suspicious &= or |= constant expression")
Signed-off-by: NColin Ian King <colin.king@canonical.com>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

The elliptic curve arithmetic library used by the EC-DH KPP implementation
assumes big endian byte order, and unconditionally reverses the byte
and word order of multi-limb quantities. On big endian systems, the byte
reordering is not necessary, while the word ordering needs to be retained.

So replace the __swab64() invocation with a call to be64_to_cpu() which
should do the right thing for both little and big endian builds.

Fixes: 3c4b2390 ("crypto: ecdh - Add ECDH software support")
Cc: <stable@vger.kernel.org> # v4.9+
Signed-off-by: NArd Biesheuvel <ard.biesheuvel@linaro.org>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

Move the call to devm_of_platform_populate() at the end of
caam_probe(), so we won't try to add any child devices until all of
the initialization is finished successfully.
Signed-off-by: NAndrey Smirnov <andrew.smirnov@gmail.com>
Cc: Chris Healy <cphealy@gmail.com>
Cc: Lucas Stach <l.stach@pengutronix.de>
Cc: Horia Geantă <horia.geanta@nxp.com>
Cc: Herbert Xu <herbert@gondor.apana.org.au>
Cc: Iuliana Prodan <iuliana.prodan@nxp.com>
Cc: linux-crypto@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Reviewed-by: NHoria Geantă <horia.geanta@nxp.com>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

Use devres to de-initialize the RNG and drop explicit de-initialization
code in caam_remove().
Signed-off-by: NAndrey Smirnov <andrew.smirnov@gmail.com>
Reviewed-by: NHoria Geantă <horia.geanta@nxp.com>
Cc: Chris Healy <cphealy@gmail.com>
Cc: Lucas Stach <l.stach@pengutronix.de>
Cc: Horia Geantă <horia.geanta@nxp.com>
Cc: Herbert Xu <herbert@gondor.apana.org.au>
Cc: Iuliana Prodan <iuliana.prodan@nxp.com>
Cc: linux-crypto@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

Use devres to de-initialize the QI and drop explicit de-initialization
code in caam_remove().
Signed-off-by: NAndrey Smirnov <andrew.smirnov@gmail.com>
Reviewed-by: NHoria Geantă <horia.geanta@nxp.com>
Cc: Chris Healy <cphealy@gmail.com>
Cc: Lucas Stach <l.stach@pengutronix.de>
Cc: Horia Geantă <horia.geanta@nxp.com>
Cc: Herbert Xu <herbert@gondor.apana.org.au>
Cc: Iuliana Prodan <iuliana.prodan@nxp.com>
Cc: linux-crypto@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

Use devres to de-initialize the RNG and drop explicit de-initialization
code in caam_remove().
Signed-off-by: NAndrey Smirnov <andrew.smirnov@gmail.com>
Cc: Chris Healy <cphealy@gmail.com>
Cc: Lucas Stach <l.stach@pengutronix.de>
Cc: Horia Geantă <horia.geanta@nxp.com>
Cc: Herbert Xu <herbert@gondor.apana.org.au>
Cc: Iuliana Prodan <iuliana.prodan@nxp.com>
Cc: linux-crypto@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Reviewed-by: NHoria Geantă <horia.geanta@nxp.com>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

Use devres to remove debugfs and drop corresponding
debugfs_remove_recursive() call.
Signed-off-by: NAndrey Smirnov <andrew.smirnov@gmail.com>
Reviewed-by: NHoria Geantă <horia.geanta@nxp.com>
Cc: Chris Healy <cphealy@gmail.com>
Cc: Lucas Stach <l.stach@pengutronix.de>
Cc: Horia Geantă <horia.geanta@nxp.com>
Cc: Herbert Xu <herbert@gondor.apana.org.au>
Cc: Iuliana Prodan <iuliana.prodan@nxp.com>
Cc: linux-crypto@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

Use devres to unmap memory and drop corresponding iounmap() call.
Signed-off-by: NAndrey Smirnov <andrew.smirnov@gmail.com>
Reviewed-by: NHoria Geantă <horia.geanta@nxp.com>
Cc: Chris Healy <cphealy@gmail.com>
Cc: Lucas Stach <l.stach@pengutronix.de>
Cc: Horia Geantă <horia.geanta@nxp.com>
Cc: Herbert Xu <herbert@gondor.apana.org.au>
Cc: Iuliana Prodan <iuliana.prodan@nxp.com>
Cc: linux-crypto@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

When runtime-pm is disabled, we get a few harmless warnings:

drivers/char/hw_random/omap3-rom-rng.c:65:12: error: unused function 'omap_rom_rng_runtime_suspend' [-Werror,-Wunused-function]
drivers/char/hw_random/omap3-rom-rng.c:81:12: error: unused function 'omap_rom_rng_runtime_resume' [-Werror,-Wunused-function]

Mark these functions as __maybe_unused so gcc can drop them
silently.

Fixes: 8d9d4bdc ("hwrng: omap3-rom - Use runtime PM instead of custom functions")
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
Reviewed-by: NSebastian Reichel <sebastian.reichel@collabora.com>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

This fixes a bunch of endianness related sparse warnings reported by the
kbuild test robot as well as Ben Dooks.

Credits for the fix to safexcel.c go to Ben Dooks.
Reported-by: Nkbuild test robot <lkp@intel.com>
Reported-by: NBen Dooks <ben.dooks@codethink.co.uk>
Signed-off-by: NPascal van Leeuwen <pvanleeuwen@verimatrix.com>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

A warning is found by the static code analysis tool:
  "Identical condition 'err', second condition is always false"

Fix this by adding return value of skcipher_walk_done().

Fixes: 67cfa5d3 ("crypto: arm64/aes-neonbs - implement ciphertext stealing for XTS")
Signed-off-by: NYunfeng Ye <yeyunfeng@huawei.com>
Acked-by: NArd Biesheuvel <ard.biesheuvel@linaro.org>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

A NULL-pointer dereference was reported in fedora bz#1762199 while
reshaping a raid6 array after adding a fifth drive to an existing
array.

[   47.343549] md/raid:md0: raid level 6 active with 3 out of 5 devices, algorithm 2
[   47.804017] md0: detected capacity change from 0 to 7885289422848
[   47.822083] Unable to handle kernel read from unreadable memory at virtual address 0000000000000000
...
[   47.940477] CPU: 1 PID: 14210 Comm: md0_raid6 Tainted: G        W         5.2.18-200.fc30.aarch64 #1
[   47.949594] Hardware name: AMD Overdrive/Supercharger/To be filled by O.E.M., BIOS ROD1002C 04/08/2016
[   47.958886] pstate: 00400085 (nzcv daIf +PAN -UAO)
[   47.963668] pc : __list_del_entry_valid+0x2c/0xa8
[   47.968366] lr : ccp_tx_submit+0x84/0x168 [ccp]
[   47.972882] sp : ffff00001369b970
[   47.976184] x29: ffff00001369b970 x28: ffff00001369bdb8
[   47.981483] x27: 00000000ffffffff x26: ffff8003b758af70
[   47.986782] x25: ffff8003b758b2d8 x24: ffff8003e6245818
[   47.992080] x23: 0000000000000000 x22: ffff8003e62450c0
[   47.997379] x21: ffff8003dfd6add8 x20: 0000000000000003
[   48.002678] x19: ffff8003e6245100 x18: 0000000000000000
[   48.007976] x17: 0000000000000000 x16: 0000000000000000
[   48.013274] x15: 0000000000000000 x14: 0000000000000000
[   48.018572] x13: ffff7e000ef83a00 x12: 0000000000000001
[   48.023870] x11: ffff000010eff998 x10: 00000000000019a0
[   48.029169] x9 : 0000000000000000 x8 : ffff8003e6245180
[   48.034467] x7 : 0000000000000000 x6 : 000000000000003f
[   48.039766] x5 : 0000000000000040 x4 : ffff8003e0145080
[   48.045064] x3 : dead000000000200 x2 : 0000000000000000
[   48.050362] x1 : 0000000000000000 x0 : ffff8003e62450c0
[   48.055660] Call trace:
[   48.058095]  __list_del_entry_valid+0x2c/0xa8
[   48.062442]  ccp_tx_submit+0x84/0x168 [ccp]
[   48.066615]  async_tx_submit+0x224/0x368 [async_tx]
[   48.071480]  async_trigger_callback+0x68/0xfc [async_tx]
[   48.076784]  ops_run_biofill+0x178/0x1e8 [raid456]
[   48.081566]  raid_run_ops+0x248/0x818 [raid456]
[   48.086086]  handle_stripe+0x864/0x1208 [raid456]
[   48.090781]  handle_active_stripes.isra.0+0xb0/0x278 [raid456]
[   48.096604]  raid5d+0x378/0x618 [raid456]
[   48.100602]  md_thread+0xa0/0x150
[   48.103905]  kthread+0x104/0x130
[   48.107122]  ret_from_fork+0x10/0x18
[   48.110686] Code: d2804003 f2fbd5a3 eb03003f 54000320 (f9400021)
[   48.116766] ---[ end trace 23f390a527f7ad77 ]---

ccp_tx_submit is passed a dma_async_tx_descriptor which is contained in
a ccp_dma_desc and adds it to a ccp channel's pending list:

	list_del(&desc->entry);
	list_add_tail(&desc->entry, &chan->pending);

The problem is that desc->entry may be uninitialized in the
async_trigger_callback path where the descriptor was gotten
from ccp_prep_dma_interrupt which got it from ccp_alloc_dma_desc
which doesn't initialize the desc->entry list head. So, just
initialize the list head to avoid the problem.

Cc: <stable@vger.kernel.org>
Reported-by: NSahaj Sarup <sahajsarup@gmail.com>
Signed-off-by: NMark Salter <msalter@redhat.com>
Acked-by: NGary R Hook <gary.hook@amd.com>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

Variables of type atomic{,64}_t can be used fine with
debugfs_create_u{32,64}, when passing a pointer to the embedded counter.
This allows to get rid of the casts, which prevented compiler checks.
Signed-off-by: NGeert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

Check early whether device registers can be accessed. Some BIOSes have
a broken security policy that prevents access to the device registers,
and return values from ioread() can be misinterpreted. If a read of
a feature register returns a -1, we may not be able to access
any device register, so report the problem and suggestion, and return.

For the PSP, the feature register is checked. For the CCP, the queue
register is checked.
Signed-off-by: NGary R Hook <gary.hook@amd.com>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

If an AMD BIOS makes zero CCP queues available to the driver, the
device is unavailable and therefore can't be activated. When this
happens, report the status but don't report a (non-existent)
failure. The CCP will be unactivated.
Signed-off-by: NGary R Hook <gary.hook@amd.com>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

This patch fixes following sparse warning:

qm.c:345:33: warning: cast removes address space '<asn:2>' of expression
qm.c:359:20: warning: incorrect type in assignment (different base types)
qm.c:359:20:    expected restricted __le16 [usertype] w0
qm.c:359:20:    got int
qm.c:362:27: warning: incorrect type in assignment (different base types)
qm.c:362:27:    expected restricted __le16 [usertype] queue_num
qm.c:362:27:    got unsigned short [usertype] queue
qm.c:363:24: warning: incorrect type in assignment (different base types)
qm.c:363:24:    expected restricted __le32 [usertype] base_l
qm.c:363:24:    got unsigned int [usertype]
qm.c:364:24: warning: incorrect type in assignment (different base types)
qm.c:364:24:    expected restricted __le32 [usertype] base_h
qm.c:364:24:    got unsigned int [usertype]
qm.c:451:22: warning: restricted __le32 degrades to integer
qm.c:471:24: warning: restricted __le16 degrades to integer
......
qm.c:1617:19: warning: incorrect type in assignment (different base types)
qm.c:1617:19:    expected restricted __le32 [usertype] dw6
qm.c:1617:19:    got int
qm.c:1891:24: warning: incorrect type in return expression (different base types)
qm.c:1891:24:    expected int
qm.c:1891:24:    got restricted pci_ers_result_t
qm.c:1894:40: warning: incorrect type in return expression (different base types)
qm.c:1894:40:    expected int
qm.c:1894:40:    got restricted pci_ers_result_t
Signed-off-by: NShukun Tan <tanshukun1@huawei.com>
Signed-off-by: NZhou Wang <wangzhou1@hisilicon.com>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

This patch fixes following sparse warning:
zip_main.c:87:1: warning: symbol 'hisi_zip_list' was not declared.
Should it be static?
zip_main.c:88:1: warning: symbol 'hisi_zip_list_lock' was not declared.
Should it be static?
zip_main.c:948:68: warning: Using plain integer as NULL pointer
Signed-off-by: NShukun Tan <tanshukun1@huawei.com>
Signed-off-by: NZhou Wang <wangzhou1@hisilicon.com>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

This patch fix sparse warning:
zip_crypto.c:425:26: warning: Using plain integer as NULL pointer

Replaces assignment of 0 to pointer with NULL assignment.
Signed-off-by: NShukun Tan <tanshukun1@huawei.com>
Signed-off-by: NZhou Wang <wangzhou1@hisilicon.com>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

Tiny fix to make QM/ZIP error callback print clear and right. If one version
hardware does not support error handling, we directly print this.

And QM is embedded in ZIP, we can use ZIP print only, so remove unnecessary
QM print.
Signed-off-by: NZhou Wang <wangzhou1@hisilicon.com>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

This patch fixes the following warnings:
drivers/crypto/ccree/cc_aead.c:630:5-12: WARNING: Unsigned expression
compared with zero: seq_len > 0
Signed-off-by: NTian Tao <tiantao6@huawei.com>

v2:
change hmac_setkey() return type to unsigned int to fix the warning.
Acked-by: NGilad Ben-Yossef <gilad@benyossef.com>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

SEV INIT command loads the SEV related persistent data from NVS
and initializes the platform context. The firmware validates the
persistent state. If validation fails, the firmware will reset
the persisent state and return an integrity check failure status.

At this point, a subsequent INIT command should succeed, so retry
the command. The INIT command retry is only done during driver
initialization.

Additional enums along with SEV_RET_SECURE_DATA_INVALID are added
to sev_ret_code to maintain continuity and relevance of enum values.
Signed-off-by: NAshish Kalra <ashish.kalra@amd.com>
Acked-by: NDavid Rientjes <rientjes@google.com>
Reviewed-by: NBrijesh Singh <brijesh.singh@amd.com>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

This patch adds support for the amlogic GXL cryptographic offloader present
on GXL SoCs.

This driver supports AES cipher in CBC/ECB mode.
Signed-off-by: NCorentin Labbe <clabbe@baylibre.com>
Reviewed-by: NNeil Armstrong <narmstrong@baylibre.com>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

I will maintain the amlogic crypto driver.
Signed-off-by: NCorentin Labbe <clabbe@baylibre.com>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

This patch adds documentation for Device-Tree bindings for the
Amlogic GXL cryptographic offloader driver.
Reviewed-by: NRob Herring <robh@kernel.org>
Signed-off-by: NCorentin Labbe <clabbe@baylibre.com>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

The driver uses a couple of buffers that seem to
be __be32 or __be64 fields, but declares them as
u32. This means there are a number of warnings
from sparse due to casting to/from __beXXX.

Fix these by changing the types of the buffer
and the associated variables.

drivers/crypto/atmel-aes.c:1023:15: warning: cast to restricted __be32
drivers/crypto/atmel-aes.c:1023:15: warning: cast to restricted __be32
drivers/crypto/atmel-aes.c:1023:15: warning: cast to restricted __be32
drivers/crypto/atmel-aes.c:1023:15: warning: cast to restricted __be32
drivers/crypto/atmel-aes.c:1023:15: warning: cast to restricted __be32
drivers/crypto/atmel-aes.c:1023:15: warning: cast to restricted __be32
drivers/crypto/atmel-aes.c:1059:28: warning: incorrect type in assignment (different base types)
drivers/crypto/atmel-aes.c:1059:28:    expected unsigned int
drivers/crypto/atmel-aes.c:1059:28:    got restricted __be32 [usertype]
drivers/crypto/atmel-aes.c:1550:28: warning: incorrect type in assignment (different base types)
drivers/crypto/atmel-aes.c:1550:28:    expected unsigned int
drivers/crypto/atmel-aes.c:1550:28:    got restricted __be32 [usertype]
drivers/crypto/atmel-aes.c:1561:39: warning: incorrect type in assignment (different base types)
drivers/crypto/atmel-aes.c:1561:39:    expected unsigned long long [usertype]
drivers/crypto/atmel-aes.c:1561:39:    got restricted __be64 [usertype]
drivers/crypto/atmel-aes.c:1599:17: warning: cast to restricted __be32
drivers/crypto/atmel-aes.c:1599:17: warning: cast to restricted __be32
drivers/crypto/atmel-aes.c:1599:17: warning: cast to restricted __be32
drivers/crypto/atmel-aes.c:1599:17: warning: cast to restricted __be32
drivers/crypto/atmel-aes.c:1599:17: warning: cast to restricted __be32
drivers/crypto/atmel-aes.c:1599:17: warning: cast to restricted __be32
drivers/crypto/atmel-aes.c:1599:17: warning: cast to restricted __be32
drivers/crypto/atmel-aes.c:1599:17: warning: cast to restricted __be32
drivers/crypto/atmel-aes.c:1599:17: warning: cast to restricted __be32
drivers/crypto/atmel-aes.c:1599:17: warning: cast to restricted __be32
drivers/crypto/atmel-aes.c:1599:17: warning: cast to restricted __be32
drivers/crypto/atmel-aes.c:1599:17: warning: cast to restricted __be32
drivers/crypto/atmel-aes.c:1599:17: warning: cast to restricted __be32
drivers/crypto/atmel-aes.c:1599:17: warning: cast to restricted __be32
drivers/crypto/atmel-aes.c:1599:17: warning: cast to restricted __be32
drivers/crypto/atmel-aes.c:1599:17: warning: cast to restricted __be32
drivers/crypto/atmel-aes.c:1599:17: warning: cast to restricted __be32
drivers/crypto/atmel-aes.c:1599:17: warning: cast to restricted __be32
drivers/crypto/atmel-aes.c:1599:17: warning: cast to restricted __be32
drivers/crypto/atmel-aes.c:1599:17: warning: cast to restricted __be32
drivers/crypto/atmel-aes.c:1599:17: warning: cast to restricted __be32
drivers/crypto/atmel-aes.c:1599:17: warning: cast to restricted __be32
drivers/crypto/atmel-aes.c:1599:17: warning: cast to restricted __be32
drivers/crypto/atmel-aes.c:1599:17: warning: cast to restricted __be32
drivers/crypto/atmel-aes.c:1599:17: warning: cast to restricted __be32
drivers/crypto/atmel-aes.c:1599:17: warning: cast to restricted __be32
drivers/crypto/atmel-aes.c:1599:17: warning: cast to restricted __be32
drivers/crypto/atmel-aes.c:1599:17: warning: cast to restricted __be32
drivers/crypto/atmel-aes.c:1599:17: warning: cast to restricted __be32
drivers/crypto/atmel-aes.c:1599:17: warning: cast to restricted __be32
drivers/crypto/atmel-aes.c:1599:17: warning: cast to restricted __be32
drivers/crypto/atmel-aes.c:1599:17: warning: cast to restricted __be32
drivers/crypto/atmel-aes.c:1599:17: warning: cast to restricted __be32
drivers/crypto/atmel-aes.c:1599:17: warning: cast to restricted __be32
drivers/crypto/atmel-aes.c:1599:17: warning: cast to restricted __be32
drivers/crypto/atmel-aes.c:1599:17: warning: cast to restricted __be32
drivers/crypto/atmel-aes.c:1599:15: warning: incorrect type in assignment (different base types)
drivers/crypto/atmel-aes.c:1599:15:    expected unsigned int [usertype]
drivers/crypto/atmel-aes.c:1599:15:    got restricted __be32 [usertype]
drivers/crypto/atmel-aes.c:1692:17: warning: incorrect type in assignment (different base types)
drivers/crypto/atmel-aes.c:1692:17:    expected unsigned long long [usertype]
drivers/crypto/atmel-aes.c:1692:17:    got restricted __be64 [usertype]
drivers/crypto/atmel-aes.c:1693:17: warning: incorrect type in assignment (different base types)
drivers/crypto/atmel-aes.c:1693:17:    expected unsigned long long [usertype]
drivers/crypto/atmel-aes.c:1693:17:    got restricted __be64 [usertype]
drivers/crypto/atmel-aes.c:1888:63: warning: incorrect type in initializer (different base types)
drivers/crypto/atmel-aes.c:1888:63:    expected unsigned int
drivers/crypto/atmel-aes.c:1888:63:    got restricted __le32 [usertype]
Signed-off-by: NBen Dooks <ben.dooks@codethink.co.uk>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

Use devm_platform_ioremap_resource() to simplify the code a bit.
This is detected by coccinelle.
Signed-off-by: NYueHaibing <yuehaibing@huawei.com>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>