--- /dev/null
+From bed903167ae5b5532eda5d7db26de451bd232da5 Mon Sep 17 00:00:00 2001
+From: Marek Szyprowski <m.szyprowski@samsung.com>
+Date: Thu, 12 Sep 2019 09:36:02 +0200
+Subject: arm64: dts: exynos: Revert "Remove unneeded address space mapping for soc node"
+
+From: Marek Szyprowski <m.szyprowski@samsung.com>
+
+commit bed903167ae5b5532eda5d7db26de451bd232da5 upstream.
+
+Commit ef72171b3621 ("arm64: dts: exynos: Remove unneeded address space
+mapping for soc node") changed the address and size cells in root node from
+2 to 1, but /memory nodes for the affected boards were not updated. This
+went unnoticed on Exynos5433-based TM2(e) boards, because they use u-boot,
+which updates /memory node to the correct values. On the other hand, the
+mentioned commit broke boot on Exynos7-based Espresso board, which
+bootloader doesn't touch /memory node at all.
+
+This patch reverts commit ef72171b3621 ("arm64: dts: exynos: Remove
+unneeded address space mapping for soc node"), so Exynos5433 and Exynos7
+SoCs again matches other ARM64 platforms with 64bit mappings in root
+node.
+
+Reported-by: Alim Akhtar <alim.akhtar@samsung.com>
+Fixes: ef72171b3621 ("arm64: dts: exynos: Remove unneeded address space mapping for soc node")
+Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
+Cc: <stable@vger.kernel.org> # 5.3.x: 72ddcf6aa224 arm64: dts: exynos: Move GPU under /soc node for Exynos5433
+Cc: <stable@vger.kernel.org> # 5.3.x: ede87c3a2bdb arm64: dts: exynos: Move GPU under /soc node for Exynos7
+Cc: <stable@vger.kernel.org> # 4.18.x
+Tested-by: Alim Akhtar <alim.akhtar@samsung.com>
+Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/arm64/boot/dts/exynos/exynos5433.dtsi | 6 +++---
+ arch/arm64/boot/dts/exynos/exynos7.dtsi | 6 +++---
+ 2 files changed, 6 insertions(+), 6 deletions(-)
+
+--- a/arch/arm64/boot/dts/exynos/exynos5433.dtsi
++++ b/arch/arm64/boot/dts/exynos/exynos5433.dtsi
+@@ -18,8 +18,8 @@
+
+ / {
+ compatible = "samsung,exynos5433";
+- #address-cells = <1>;
+- #size-cells = <1>;
++ #address-cells = <2>;
++ #size-cells = <2>;
+
+ interrupt-parent = <&gic>;
+
+@@ -235,7 +235,7 @@
+ compatible = "simple-bus";
+ #address-cells = <1>;
+ #size-cells = <1>;
+- ranges;
++ ranges = <0x0 0x0 0x0 0x18000000>;
+
+ arm_a53_pmu {
+ compatible = "arm,cortex-a53-pmu", "arm,armv8-pmuv3";
+--- a/arch/arm64/boot/dts/exynos/exynos7.dtsi
++++ b/arch/arm64/boot/dts/exynos/exynos7.dtsi
+@@ -12,8 +12,8 @@
+ / {
+ compatible = "samsung,exynos7";
+ interrupt-parent = <&gic>;
+- #address-cells = <1>;
+- #size-cells = <1>;
++ #address-cells = <2>;
++ #size-cells = <2>;
+
+ aliases {
+ pinctrl0 = &pinctrl_alive;
+@@ -70,7 +70,7 @@
+ compatible = "simple-bus";
+ #address-cells = <1>;
+ #size-cells = <1>;
+- ranges;
++ ranges = <0 0 0 0x18000000>;
+
+ chipid@10000000 {
+ compatible = "samsung,exynos4210-chipid";
--- /dev/null
+From 64e7f852c47ce99f6c324c46d6a299a5a7ebead9 Mon Sep 17 00:00:00 2001
+From: Ayush Sawal <ayush.sawal@chelsio.com>
+Date: Fri, 4 Oct 2019 10:50:58 -0700
+Subject: crypto: af_alg - cast ki_complete ternary op to int
+
+From: Ayush Sawal <ayush.sawal@chelsio.com>
+
+commit 64e7f852c47ce99f6c324c46d6a299a5a7ebead9 upstream.
+
+when libkcapi test is executed using HW accelerator, cipher operation
+return -74.Since af_alg_async_cb->ki_complete treat err as unsigned int,
+libkcapi receive 429467222 even though it expect -ve value.
+
+Hence its required to cast resultlen to int so that proper
+error is returned to libkcapi.
+
+AEAD one shot non-aligned test 2(libkcapi test)
+./../bin/kcapi -x 10 -c "gcm(aes)" -i 7815d4b06ae50c9c56e87bd7
+-k ea38ac0c9b9998c80e28fb496a2b88d9 -a
+"853f98a750098bec1aa7497e979e78098155c877879556bb51ddeb6374cbaefc"
+-t "c4ce58985b7203094be1d134c1b8ab0b" -q
+"b03692f86d1b8b39baf2abb255197c98"
+
+Fixes: d887c52d6ae4 ("crypto: algif_aead - overhaul memory management")
+Cc: <stable@vger.kernel.org>
+Signed-off-by: Ayush Sawal <ayush.sawal@chelsio.com>
+Signed-off-by: Atul Gupta <atul.gupta@chelsio.com>
+Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
+Signed-off-by: Ayush Sawal <ayush.sawal@chelsio.com>
+Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ crypto/af_alg.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/crypto/af_alg.c
++++ b/crypto/af_alg.c
+@@ -1058,7 +1058,7 @@ void af_alg_async_cb(struct crypto_async
+ af_alg_free_resources(areq);
+ sock_put(sk);
+
+- iocb->ki_complete(iocb, err ? err : resultlen, 0);
++ iocb->ki_complete(iocb, err ? err : (int)resultlen, 0);
+ }
+ EXPORT_SYMBOL_GPL(af_alg_async_cb);
+
--- /dev/null
+From 86ef1dfcb561473fbf5e199d58d18c55554d78be Mon Sep 17 00:00:00 2001
+From: Tudor Ambarus <tudor.ambarus@microchip.com>
+Date: Fri, 4 Oct 2019 08:55:37 +0000
+Subject: crypto: atmel-aes - Fix IV handling when req->nbytes < ivsize
+
+From: Tudor Ambarus <tudor.ambarus@microchip.com>
+
+commit 86ef1dfcb561473fbf5e199d58d18c55554d78be upstream.
+
+commit 394a9e044702 ("crypto: cfb - add missing 'chunksize' property")
+adds a test vector where the input length is smaller than the IV length
+(the second test vector). This revealed a NULL pointer dereference in
+the atmel-aes driver, that is caused by passing an incorrect offset in
+scatterwalk_map_and_copy() when atmel_aes_complete() is called.
+
+Do not save the IV in req->info of ablkcipher_request (or equivalently
+req->iv of skcipher_request) when req->nbytes < ivsize, because the IV
+will not be further used.
+
+While touching the code, modify the type of ivsize from int to
+unsigned int, to comply with the return type of
+crypto_ablkcipher_ivsize().
+
+Fixes: 91308019ecb4 ("crypto: atmel-aes - properly set IV after {en,de}crypt")
+Cc: <stable@vger.kernel.org>
+Signed-off-by: Tudor Ambarus <tudor.ambarus@microchip.com>
+Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/crypto/atmel-aes.c | 53 +++++++++++++++++++++++++--------------------
+ 1 file changed, 30 insertions(+), 23 deletions(-)
+
+--- a/drivers/crypto/atmel-aes.c
++++ b/drivers/crypto/atmel-aes.c
+@@ -493,6 +493,29 @@ static inline bool atmel_aes_is_encrypt(
+ static void atmel_aes_authenc_complete(struct atmel_aes_dev *dd, int err);
+ #endif
+
++static void atmel_aes_set_iv_as_last_ciphertext_block(struct atmel_aes_dev *dd)
++{
++ struct ablkcipher_request *req = ablkcipher_request_cast(dd->areq);
++ struct atmel_aes_reqctx *rctx = ablkcipher_request_ctx(req);
++ struct crypto_ablkcipher *ablkcipher = crypto_ablkcipher_reqtfm(req);
++ unsigned int ivsize = crypto_ablkcipher_ivsize(ablkcipher);
++
++ if (req->nbytes < ivsize)
++ return;
++
++ if (rctx->mode & AES_FLAGS_ENCRYPT) {
++ scatterwalk_map_and_copy(req->info, req->dst,
++ req->nbytes - ivsize, ivsize, 0);
++ } else {
++ if (req->src == req->dst)
++ memcpy(req->info, rctx->lastc, ivsize);
++ else
++ scatterwalk_map_and_copy(req->info, req->src,
++ req->nbytes - ivsize,
++ ivsize, 0);
++ }
++}
++
+ static inline int atmel_aes_complete(struct atmel_aes_dev *dd, int err)
+ {
+ #ifdef CONFIG_CRYPTO_DEV_ATMEL_AUTHENC
+@@ -503,26 +526,8 @@ static inline int atmel_aes_complete(str
+ clk_disable(dd->iclk);
+ dd->flags &= ~AES_FLAGS_BUSY;
+
+- if (!dd->ctx->is_aead) {
+- struct ablkcipher_request *req =
+- ablkcipher_request_cast(dd->areq);
+- struct atmel_aes_reqctx *rctx = ablkcipher_request_ctx(req);
+- struct crypto_ablkcipher *ablkcipher =
+- crypto_ablkcipher_reqtfm(req);
+- int ivsize = crypto_ablkcipher_ivsize(ablkcipher);
+-
+- if (rctx->mode & AES_FLAGS_ENCRYPT) {
+- scatterwalk_map_and_copy(req->info, req->dst,
+- req->nbytes - ivsize, ivsize, 0);
+- } else {
+- if (req->src == req->dst) {
+- memcpy(req->info, rctx->lastc, ivsize);
+- } else {
+- scatterwalk_map_and_copy(req->info, req->src,
+- req->nbytes - ivsize, ivsize, 0);
+- }
+- }
+- }
++ if (!dd->ctx->is_aead)
++ atmel_aes_set_iv_as_last_ciphertext_block(dd);
+
+ if (dd->is_async)
+ dd->areq->complete(dd->areq, err);
+@@ -1128,10 +1133,12 @@ static int atmel_aes_crypt(struct ablkci
+ rctx->mode = mode;
+
+ if (!(mode & AES_FLAGS_ENCRYPT) && (req->src == req->dst)) {
+- int ivsize = crypto_ablkcipher_ivsize(ablkcipher);
++ unsigned int ivsize = crypto_ablkcipher_ivsize(ablkcipher);
+
+- scatterwalk_map_and_copy(rctx->lastc, req->src,
+- (req->nbytes - ivsize), ivsize, 0);
++ if (req->nbytes >= ivsize)
++ scatterwalk_map_and_copy(rctx->lastc, req->src,
++ req->nbytes - ivsize,
++ ivsize, 0);
+ }
+
+ return atmel_aes_handle_queue(dd, &req->base);
--- /dev/null
+From 691505a803a7f223b2af621848d581259c61f77d Mon Sep 17 00:00:00 2001
+From: Mark Salter <msalter@redhat.com>
+Date: Mon, 21 Oct 2019 11:29:49 -0400
+Subject: crypto: ccp - fix uninitialized list head
+
+From: Mark Salter <msalter@redhat.com>
+
+commit 691505a803a7f223b2af621848d581259c61f77d upstream.
+
+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: Sahaj Sarup <sahajsarup@gmail.com>
+Signed-off-by: Mark Salter <msalter@redhat.com>
+Acked-by: Gary R Hook <gary.hook@amd.com>
+Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/crypto/ccp/ccp-dmaengine.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/drivers/crypto/ccp/ccp-dmaengine.c
++++ b/drivers/crypto/ccp/ccp-dmaengine.c
+@@ -340,6 +340,7 @@ static struct ccp_dma_desc *ccp_alloc_dm
+ desc->tx_desc.flags = flags;
+ desc->tx_desc.tx_submit = ccp_tx_submit;
+ desc->ccp = chan->ccp;
++ INIT_LIST_HEAD(&desc->entry);
+ INIT_LIST_HEAD(&desc->pending);
+ INIT_LIST_HEAD(&desc->active);
+ desc->status = DMA_IN_PROGRESS;
--- /dev/null
+From 746c908c4d72e49068ab216c3926d2720d71a90d Mon Sep 17 00:00:00 2001
+From: Christian Lamparter <chunkeey@gmail.com>
+Date: Thu, 31 Oct 2019 17:14:38 +0100
+Subject: crypto: crypto4xx - fix double-free in crypto4xx_destroy_sdr
+
+From: Christian Lamparter <chunkeey@gmail.com>
+
+commit 746c908c4d72e49068ab216c3926d2720d71a90d upstream.
+
+This patch fixes a crash that can happen during probe
+when the available dma memory is not enough (this can
+happen if the crypto4xx is built as a module).
+
+The descriptor window mapping would end up being free'd
+twice, once in crypto4xx_build_pdr() and the second time
+in crypto4xx_destroy_sdr().
+
+Fixes: 5d59ad6eea82 ("crypto: crypto4xx - fix crypto4xx_build_pdr, crypto4xx_build_sdr leak")
+Cc: <stable@vger.kernel.org>
+Signed-off-by: Christian Lamparter <chunkeey@gmail.com>
+Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/crypto/amcc/crypto4xx_core.c | 6 +-----
+ 1 file changed, 1 insertion(+), 5 deletions(-)
+
+--- a/drivers/crypto/amcc/crypto4xx_core.c
++++ b/drivers/crypto/amcc/crypto4xx_core.c
+@@ -373,12 +373,8 @@ static u32 crypto4xx_build_sdr(struct cr
+ dma_alloc_coherent(dev->core_dev->device,
+ PPC4XX_SD_BUFFER_SIZE * PPC4XX_NUM_SD,
+ &dev->scatter_buffer_pa, GFP_ATOMIC);
+- if (!dev->scatter_buffer_va) {
+- dma_free_coherent(dev->core_dev->device,
+- sizeof(struct ce_sd) * PPC4XX_NUM_SD,
+- dev->sdr, dev->sdr_pa);
++ if (!dev->scatter_buffer_va)
+ return -ENOMEM;
+- }
+
+ for (i = 0; i < PPC4XX_NUM_SD; i++) {
+ dev->sdr[i].ptr = dev->scatter_buffer_pa +
--- /dev/null
+From f398243e9fd6a3a059c1ea7b380c40628dbf0c61 Mon Sep 17 00:00:00 2001
+From: Ard Biesheuvel <ardb@kernel.org>
+Date: Wed, 23 Oct 2019 11:50:44 +0200
+Subject: crypto: ecdh - fix big endian bug in ECC library
+
+From: Ard Biesheuvel <ard.biesheuvel@linaro.org>
+
+commit f398243e9fd6a3a059c1ea7b380c40628dbf0c61 upstream.
+
+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: 3c4b23901a0c ("crypto: ecdh - Add ECDH software support")
+Cc: <stable@vger.kernel.org> # v4.9+
+Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
+Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ crypto/ecc.c | 3 ++-
+ 1 file changed, 2 insertions(+), 1 deletion(-)
+
+--- a/crypto/ecc.c
++++ b/crypto/ecc.c
+@@ -906,10 +906,11 @@ static void ecc_point_mult(struct ecc_po
+ static inline void ecc_swap_digits(const u64 *in, u64 *out,
+ unsigned int ndigits)
+ {
++ const __be64 *src = (__force __be64 *)in;
+ int i;
+
+ for (i = 0; i < ndigits; i++)
+- out[i] = __swab64(in[ndigits - 1 - i]);
++ out[i] = be64_to_cpu(src[ndigits - 1 - i]);
+ }
+
+ static int __ecc_is_key_valid(const struct ecc_curve *curve,
--- /dev/null
+From 504582e8e40b90b8f8c58783e2d1e4f6a2b71a3a Mon Sep 17 00:00:00 2001
+From: Ard Biesheuvel <ardb@kernel.org>
+Date: Sat, 5 Oct 2019 11:11:10 +0200
+Subject: crypto: geode-aes - switch to skcipher for cbc(aes) fallback
+
+From: Ard Biesheuvel <ard.biesheuvel@linaro.org>
+
+commit 504582e8e40b90b8f8c58783e2d1e4f6a2b71a3a upstream.
+
+Commit 79c65d179a40e145 ("crypto: cbc - Convert to skcipher") updated
+the generic CBC template wrapper from a blkcipher to a skcipher algo,
+to get away from the deprecated blkcipher interface. However, as a side
+effect, drivers that instantiate CBC transforms using the blkcipher as
+a fallback no longer work, since skciphers can wrap blkciphers but not
+the other way around. This broke the geode-aes driver.
+
+So let's fix it by moving to the sync skcipher interface when allocating
+the fallback. At the same time, align with the generic API for ECB and
+CBC by rejecting inputs that are not a multiple of the AES block size.
+
+Fixes: 79c65d179a40e145 ("crypto: cbc - Convert to skcipher")
+Cc: <stable@vger.kernel.org> # v4.20+ ONLY
+Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
+Signed-off-by: Florian Bezdeka <florian@bezdeka.de>
+Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/crypto/geode-aes.c | 57 ++++++++++++++++++++++++++-------------------
+ drivers/crypto/geode-aes.h | 2 -
+ 2 files changed, 34 insertions(+), 25 deletions(-)
+
+--- a/drivers/crypto/geode-aes.c
++++ b/drivers/crypto/geode-aes.c
+@@ -14,6 +14,7 @@
+ #include <linux/spinlock.h>
+ #include <crypto/algapi.h>
+ #include <crypto/aes.h>
++#include <crypto/skcipher.h>
+
+ #include <linux/io.h>
+ #include <linux/delay.h>
+@@ -170,13 +171,15 @@ static int geode_setkey_blk(struct crypt
+ /*
+ * The requested key size is not supported by HW, do a fallback
+ */
+- op->fallback.blk->base.crt_flags &= ~CRYPTO_TFM_REQ_MASK;
+- op->fallback.blk->base.crt_flags |= (tfm->crt_flags & CRYPTO_TFM_REQ_MASK);
++ crypto_sync_skcipher_clear_flags(op->fallback.blk, CRYPTO_TFM_REQ_MASK);
++ crypto_sync_skcipher_set_flags(op->fallback.blk,
++ tfm->crt_flags & CRYPTO_TFM_REQ_MASK);
+
+- ret = crypto_blkcipher_setkey(op->fallback.blk, key, len);
++ ret = crypto_sync_skcipher_setkey(op->fallback.blk, key, len);
+ if (ret) {
+ tfm->crt_flags &= ~CRYPTO_TFM_RES_MASK;
+- tfm->crt_flags |= (op->fallback.blk->base.crt_flags & CRYPTO_TFM_RES_MASK);
++ tfm->crt_flags |= crypto_sync_skcipher_get_flags(op->fallback.blk) &
++ CRYPTO_TFM_RES_MASK;
+ }
+ return ret;
+ }
+@@ -185,33 +188,28 @@ static int fallback_blk_dec(struct blkci
+ struct scatterlist *dst, struct scatterlist *src,
+ unsigned int nbytes)
+ {
+- unsigned int ret;
+- struct crypto_blkcipher *tfm;
+ struct geode_aes_op *op = crypto_blkcipher_ctx(desc->tfm);
++ SYNC_SKCIPHER_REQUEST_ON_STACK(req, op->fallback.blk);
+
+- tfm = desc->tfm;
+- desc->tfm = op->fallback.blk;
+-
+- ret = crypto_blkcipher_decrypt_iv(desc, dst, src, nbytes);
++ skcipher_request_set_sync_tfm(req, op->fallback.blk);
++ skcipher_request_set_callback(req, 0, NULL, NULL);
++ skcipher_request_set_crypt(req, src, dst, nbytes, desc->info);
+
+- desc->tfm = tfm;
+- return ret;
++ return crypto_skcipher_decrypt(req);
+ }
++
+ static int fallback_blk_enc(struct blkcipher_desc *desc,
+ struct scatterlist *dst, struct scatterlist *src,
+ unsigned int nbytes)
+ {
+- unsigned int ret;
+- struct crypto_blkcipher *tfm;
+ struct geode_aes_op *op = crypto_blkcipher_ctx(desc->tfm);
++ SYNC_SKCIPHER_REQUEST_ON_STACK(req, op->fallback.blk);
+
+- tfm = desc->tfm;
+- desc->tfm = op->fallback.blk;
+-
+- ret = crypto_blkcipher_encrypt_iv(desc, dst, src, nbytes);
++ skcipher_request_set_sync_tfm(req, op->fallback.blk);
++ skcipher_request_set_callback(req, 0, NULL, NULL);
++ skcipher_request_set_crypt(req, src, dst, nbytes, desc->info);
+
+- desc->tfm = tfm;
+- return ret;
++ return crypto_skcipher_encrypt(req);
+ }
+
+ static void
+@@ -311,6 +309,9 @@ geode_cbc_decrypt(struct blkcipher_desc
+ struct blkcipher_walk walk;
+ int err, ret;
+
++ if (nbytes % AES_BLOCK_SIZE)
++ return -EINVAL;
++
+ if (unlikely(op->keylen != AES_KEYSIZE_128))
+ return fallback_blk_dec(desc, dst, src, nbytes);
+
+@@ -343,6 +344,9 @@ geode_cbc_encrypt(struct blkcipher_desc
+ struct blkcipher_walk walk;
+ int err, ret;
+
++ if (nbytes % AES_BLOCK_SIZE)
++ return -EINVAL;
++
+ if (unlikely(op->keylen != AES_KEYSIZE_128))
+ return fallback_blk_enc(desc, dst, src, nbytes);
+
+@@ -370,9 +374,8 @@ static int fallback_init_blk(struct cryp
+ const char *name = crypto_tfm_alg_name(tfm);
+ struct geode_aes_op *op = crypto_tfm_ctx(tfm);
+
+- op->fallback.blk = crypto_alloc_blkcipher(name, 0,
+- CRYPTO_ALG_ASYNC | CRYPTO_ALG_NEED_FALLBACK);
+-
++ op->fallback.blk = crypto_alloc_sync_skcipher(name, 0,
++ CRYPTO_ALG_NEED_FALLBACK);
+ if (IS_ERR(op->fallback.blk)) {
+ printk(KERN_ERR "Error allocating fallback algo %s\n", name);
+ return PTR_ERR(op->fallback.blk);
+@@ -385,7 +388,7 @@ static void fallback_exit_blk(struct cry
+ {
+ struct geode_aes_op *op = crypto_tfm_ctx(tfm);
+
+- crypto_free_blkcipher(op->fallback.blk);
++ crypto_free_sync_skcipher(op->fallback.blk);
+ op->fallback.blk = NULL;
+ }
+
+@@ -424,6 +427,9 @@ geode_ecb_decrypt(struct blkcipher_desc
+ struct blkcipher_walk walk;
+ int err, ret;
+
++ if (nbytes % AES_BLOCK_SIZE)
++ return -EINVAL;
++
+ if (unlikely(op->keylen != AES_KEYSIZE_128))
+ return fallback_blk_dec(desc, dst, src, nbytes);
+
+@@ -454,6 +460,9 @@ geode_ecb_encrypt(struct blkcipher_desc
+ struct blkcipher_walk walk;
+ int err, ret;
+
++ if (nbytes % AES_BLOCK_SIZE)
++ return -EINVAL;
++
+ if (unlikely(op->keylen != AES_KEYSIZE_128))
+ return fallback_blk_enc(desc, dst, src, nbytes);
+
+--- a/drivers/crypto/geode-aes.h
++++ b/drivers/crypto/geode-aes.h
+@@ -64,7 +64,7 @@ struct geode_aes_op {
+ u8 *iv;
+
+ union {
+- struct crypto_blkcipher *blk;
++ struct crypto_sync_skcipher *blk;
+ struct crypto_cipher *cip;
+ } fallback;
+ u32 keylen;
--- /dev/null
+From ffdde5932042600c6807d46c1550b28b0db6a3bc Mon Sep 17 00:00:00 2001
+From: Navid Emamdoost <navid.emamdoost@gmail.com>
+Date: Fri, 4 Oct 2019 14:29:16 -0500
+Subject: crypto: user - fix memory leak in crypto_report
+
+From: Navid Emamdoost <navid.emamdoost@gmail.com>
+
+commit ffdde5932042600c6807d46c1550b28b0db6a3bc upstream.
+
+In crypto_report, a new skb is created via nlmsg_new(). This skb should
+be released if crypto_report_alg() fails.
+
+Fixes: a38f7907b926 ("crypto: Add userspace configuration API")
+Cc: <stable@vger.kernel.org>
+Signed-off-by: Navid Emamdoost <navid.emamdoost@gmail.com>
+Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ crypto/crypto_user.c | 4 +++-
+ 1 file changed, 3 insertions(+), 1 deletion(-)
+
+--- a/crypto/crypto_user.c
++++ b/crypto/crypto_user.c
+@@ -288,8 +288,10 @@ static int crypto_report(struct sk_buff
+ drop_alg:
+ crypto_mod_put(alg);
+
+- if (err)
++ if (err) {
++ kfree_skb(skb);
+ return err;
++ }
+
+ return nlmsg_unicast(crypto_nlsk, skb, NETLINK_CB(in_skb).portid);
+ }
--- /dev/null
+From 4f69851fbaa26b155330be35ce8ac393e93e7442 Mon Sep 17 00:00:00 2001
+From: Dan Carpenter <dan.carpenter@oracle.com>
+Date: Fri, 4 Oct 2019 13:22:51 +0300
+Subject: drm/i810: Prevent underflow in ioctl
+
+From: Dan Carpenter <dan.carpenter@oracle.com>
+
+commit 4f69851fbaa26b155330be35ce8ac393e93e7442 upstream.
+
+The "used" variables here come from the user in the ioctl and it can be
+negative. It could result in an out of bounds write.
+
+Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
+Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
+Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
+Link: https://patchwork.freedesktop.org/patch/msgid/20191004102251.GC823@mwanda
+Cc: stable@vger.kernel.org
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/gpu/drm/i810/i810_dma.c | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+--- a/drivers/gpu/drm/i810/i810_dma.c
++++ b/drivers/gpu/drm/i810/i810_dma.c
+@@ -721,7 +721,7 @@ static void i810_dma_dispatch_vertex(str
+ if (nbox > I810_NR_SAREA_CLIPRECTS)
+ nbox = I810_NR_SAREA_CLIPRECTS;
+
+- if (used > 4 * 1024)
++ if (used < 0 || used > 4 * 1024)
+ used = 0;
+
+ if (sarea_priv->dirty)
+@@ -1041,7 +1041,7 @@ static void i810_dma_dispatch_mc(struct
+ if (u != I810_BUF_CLIENT)
+ DRM_DEBUG("MC found buffer that isn't mine!\n");
+
+- if (used > 4 * 1024)
++ if (used < 0 || used > 4 * 1024)
+ used = 0;
+
+ sarea_priv->dirty = 0x7f;
--- /dev/null
+From a64fc11b9a520c55ca34d82e5ca32274f49b6b15 Mon Sep 17 00:00:00 2001
+From: Johan Hovold <johan@kernel.org>
+Date: Thu, 10 Oct 2019 15:13:30 +0200
+Subject: drm/msm: fix memleak on release
+
+From: Johan Hovold <johan@kernel.org>
+
+commit a64fc11b9a520c55ca34d82e5ca32274f49b6b15 upstream.
+
+If a process is interrupted while accessing the "gpu" debugfs file and
+the drm device struct_mutex is contended, release() could return early
+and fail to free related resources.
+
+Note that the return value from release() is ignored.
+
+Fixes: 4f776f4511c7 ("drm/msm/gpu: Convert the GPU show function to use the GPU state")
+Cc: stable <stable@vger.kernel.org> # 4.18
+Cc: Jordan Crouse <jcrouse@codeaurora.org>
+Cc: Rob Clark <robdclark@gmail.com>
+Reviewed-by: Rob Clark <robdclark@gmail.com>
+Signed-off-by: Johan Hovold <johan@kernel.org>
+Signed-off-by: Sean Paul <seanpaul@chromium.org>
+Link: https://patchwork.freedesktop.org/patch/msgid/20191010131333.23635-2-johan@kernel.org
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/gpu/drm/msm/msm_debugfs.c | 6 +-----
+ 1 file changed, 1 insertion(+), 5 deletions(-)
+
+--- a/drivers/gpu/drm/msm/msm_debugfs.c
++++ b/drivers/gpu/drm/msm/msm_debugfs.c
+@@ -53,12 +53,8 @@ static int msm_gpu_release(struct inode
+ struct msm_gpu_show_priv *show_priv = m->private;
+ struct msm_drm_private *priv = show_priv->dev->dev_private;
+ struct msm_gpu *gpu = priv->gpu;
+- int ret;
+-
+- ret = mutex_lock_interruptible(&show_priv->dev->struct_mutex);
+- if (ret)
+- return ret;
+
++ mutex_lock(&show_priv->dev->struct_mutex);
+ gpu->funcs->gpu_state_put(show_priv->state);
+ mutex_unlock(&show_priv->dev->struct_mutex);
+
--- /dev/null
+From ca185b260951d3b55108c0b95e188682d8a507b7 Mon Sep 17 00:00:00 2001
+From: Zenghui Yu <yuzenghui@huawei.com>
+Date: Tue, 29 Oct 2019 15:19:19 +0800
+Subject: KVM: arm/arm64: vgic: Don't rely on the wrong pending table
+
+From: Zenghui Yu <yuzenghui@huawei.com>
+
+commit ca185b260951d3b55108c0b95e188682d8a507b7 upstream.
+
+It's possible that two LPIs locate in the same "byte_offset" but target
+two different vcpus, where their pending status are indicated by two
+different pending tables. In such a scenario, using last_byte_offset
+optimization will lead KVM relying on the wrong pending table entry.
+Let us use last_ptr instead, which can be treated as a byte index into
+a pending table and also, can be vcpu specific.
+
+Fixes: 280771252c1b ("KVM: arm64: vgic-v3: KVM_DEV_ARM_VGIC_SAVE_PENDING_TABLES")
+Cc: stable@vger.kernel.org
+Signed-off-by: Zenghui Yu <yuzenghui@huawei.com>
+Signed-off-by: Marc Zyngier <maz@kernel.org>
+Acked-by: Eric Auger <eric.auger@redhat.com>
+Link: https://lore.kernel.org/r/20191029071919.177-4-yuzenghui@huawei.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ virt/kvm/arm/vgic/vgic-v3.c | 6 +++---
+ 1 file changed, 3 insertions(+), 3 deletions(-)
+
+--- a/virt/kvm/arm/vgic/vgic-v3.c
++++ b/virt/kvm/arm/vgic/vgic-v3.c
+@@ -375,8 +375,8 @@ retry:
+ int vgic_v3_save_pending_tables(struct kvm *kvm)
+ {
+ struct vgic_dist *dist = &kvm->arch.vgic;
+- int last_byte_offset = -1;
+ struct vgic_irq *irq;
++ gpa_t last_ptr = ~(gpa_t)0;
+ int ret;
+ u8 val;
+
+@@ -396,11 +396,11 @@ int vgic_v3_save_pending_tables(struct k
+ bit_nr = irq->intid % BITS_PER_BYTE;
+ ptr = pendbase + byte_offset;
+
+- if (byte_offset != last_byte_offset) {
++ if (ptr != last_ptr) {
+ ret = kvm_read_guest_lock(kvm, ptr, &val, 1);
+ if (ret)
+ return ret;
+- last_byte_offset = byte_offset;
++ last_ptr = ptr;
+ }
+
+ stored = val & (1U << bit_nr);
--- /dev/null
+From de1fca5d6e0105c9d33924e1247e2f386efc3ece Mon Sep 17 00:00:00 2001
+From: Paolo Bonzini <pbonzini@redhat.com>
+Date: Mon, 18 Nov 2019 12:23:00 -0500
+Subject: KVM: x86: do not modify masked bits of shared MSRs
+
+From: Paolo Bonzini <pbonzini@redhat.com>
+
+commit de1fca5d6e0105c9d33924e1247e2f386efc3ece upstream.
+
+"Shared MSRs" are guest MSRs that are written to the host MSRs but
+keep their value until the next return to userspace. They support
+a mask, so that some bits keep the host value, but this mask is
+only used to skip an unnecessary MSR write and the value written
+to the MSR is always the guest MSR.
+
+Fix this and, while at it, do not update smsr->values[slot].curr if
+for whatever reason the wrmsr fails. This should only happen due to
+reserved bits, so the value written to smsr->values[slot].curr
+will not match when the user-return notifier and the host value will
+always be restored. However, it is untidy and in rare cases this
+can actually avoid spurious WRMSRs on return to userspace.
+
+Cc: stable@vger.kernel.org
+Reviewed-by: Jim Mattson <jmattson@google.com>
+Tested-by: Jim Mattson <jmattson@google.com>
+Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/x86/kvm/x86.c | 5 +++--
+ 1 file changed, 3 insertions(+), 2 deletions(-)
+
+--- a/arch/x86/kvm/x86.c
++++ b/arch/x86/kvm/x86.c
+@@ -290,13 +290,14 @@ int kvm_set_shared_msr(unsigned slot, u6
+ struct kvm_shared_msrs *smsr = per_cpu_ptr(shared_msrs, cpu);
+ int err;
+
+- if (((value ^ smsr->values[slot].curr) & mask) == 0)
++ value = (value & mask) | (smsr->values[slot].host & ~mask);
++ if (value == smsr->values[slot].curr)
+ return 0;
+- smsr->values[slot].curr = value;
+ err = wrmsrl_safe(shared_msrs_global.msrs[slot], value);
+ if (err)
+ return 1;
+
++ smsr->values[slot].curr = value;
+ if (!smsr->registered) {
+ smsr->urn.on_user_return = kvm_on_user_return;
+ user_return_notifier_register(&smsr->urn);
--- /dev/null
+From cbbaa2727aa3ae9e0a844803da7cef7fd3b94f2b Mon Sep 17 00:00:00 2001
+From: Paolo Bonzini <pbonzini@redhat.com>
+Date: Mon, 18 Nov 2019 18:58:26 +0100
+Subject: KVM: x86: fix presentation of TSX feature in ARCH_CAPABILITIES
+
+From: Paolo Bonzini <pbonzini@redhat.com>
+
+commit cbbaa2727aa3ae9e0a844803da7cef7fd3b94f2b upstream.
+
+KVM does not implement MSR_IA32_TSX_CTRL, so it must not be presented
+to the guests. It is also confusing to have !ARCH_CAP_TSX_CTRL_MSR &&
+!RTM && ARCH_CAP_TAA_NO: lack of MSR_IA32_TSX_CTRL suggests TSX was not
+hidden (it actually was), yet the value says that TSX is not vulnerable
+to microarchitectural data sampling. Fix both.
+
+Cc: stable@vger.kernel.org
+Tested-by: Jim Mattson <jmattson@google.com>
+Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/x86/kvm/x86.c | 9 +++++++--
+ 1 file changed, 7 insertions(+), 2 deletions(-)
+
+--- a/arch/x86/kvm/x86.c
++++ b/arch/x86/kvm/x86.c
+@@ -1174,10 +1174,15 @@ u64 kvm_get_arch_capabilities(void)
+ * If TSX is disabled on the system, guests are also mitigated against
+ * TAA and clear CPU buffer mitigation is not required for guests.
+ */
+- if (boot_cpu_has_bug(X86_BUG_TAA) && boot_cpu_has(X86_FEATURE_RTM) &&
+- (data & ARCH_CAP_TSX_CTRL_MSR))
++ if (!boot_cpu_has(X86_FEATURE_RTM))
++ data &= ~ARCH_CAP_TAA_NO;
++ else if (!boot_cpu_has_bug(X86_BUG_TAA))
++ data |= ARCH_CAP_TAA_NO;
++ else if (data & ARCH_CAP_TSX_CTRL_MSR)
+ data &= ~ARCH_CAP_MDS_NO;
+
++ /* KVM does not emulate MSR_IA32_TSX_CTRL. */
++ data &= ~ARCH_CAP_TSX_CTRL_MSR;
+ return data;
+ }
+
--- /dev/null
+From ad5996d9a0e8019c3ae5151e687939369acfe044 Mon Sep 17 00:00:00 2001
+From: Sean Christopherson <sean.j.christopherson@intel.com>
+Date: Fri, 22 Nov 2019 08:58:18 -0800
+Subject: KVM: x86: Grab KVM's srcu lock when setting nested state
+
+From: Sean Christopherson <sean.j.christopherson@intel.com>
+
+commit ad5996d9a0e8019c3ae5151e687939369acfe044 upstream.
+
+Acquire kvm->srcu for the duration of ->set_nested_state() to fix a bug
+where nVMX derefences ->memslots without holding ->srcu or ->slots_lock.
+
+The other half of nested migration, ->get_nested_state(), does not need
+to acquire ->srcu as it is a purely a dump of internal KVM (and CPU)
+state to userspace.
+
+Detected as an RCU lockdep splat that is 100% reproducible by running
+KVM's state_test selftest with CONFIG_PROVE_LOCKING=y. Note that the
+failing function, kvm_is_visible_gfn(), is only checking the validity of
+a gfn, it's not actually accessing guest memory (which is more or less
+unsupported during vmx_set_nested_state() due to incorrect MMU state),
+i.e. vmx_set_nested_state() itself isn't fundamentally broken. In any
+case, setting nested state isn't a fast path so there's no reason to go
+out of our way to avoid taking ->srcu.
+
+ =============================
+ WARNING: suspicious RCU usage
+ 5.4.0-rc7+ #94 Not tainted
+ -----------------------------
+ include/linux/kvm_host.h:626 suspicious rcu_dereference_check() usage!
+
+ other info that might help us debug this:
+
+ rcu_scheduler_active = 2, debug_locks = 1
+ 1 lock held by evmcs_test/10939:
+ #0: ffff88826ffcb800 (&vcpu->mutex){+.+.}, at: kvm_vcpu_ioctl+0x85/0x630 [kvm]
+
+ stack backtrace:
+ CPU: 1 PID: 10939 Comm: evmcs_test Not tainted 5.4.0-rc7+ #94
+ Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015
+ Call Trace:
+ dump_stack+0x68/0x9b
+ kvm_is_visible_gfn+0x179/0x180 [kvm]
+ mmu_check_root+0x11/0x30 [kvm]
+ fast_cr3_switch+0x40/0x120 [kvm]
+ kvm_mmu_new_cr3+0x34/0x60 [kvm]
+ nested_vmx_load_cr3+0xbd/0x1f0 [kvm_intel]
+ nested_vmx_enter_non_root_mode+0xab8/0x1d60 [kvm_intel]
+ vmx_set_nested_state+0x256/0x340 [kvm_intel]
+ kvm_arch_vcpu_ioctl+0x491/0x11a0 [kvm]
+ kvm_vcpu_ioctl+0xde/0x630 [kvm]
+ do_vfs_ioctl+0xa2/0x6c0
+ ksys_ioctl+0x66/0x70
+ __x64_sys_ioctl+0x16/0x20
+ do_syscall_64+0x54/0x200
+ entry_SYSCALL_64_after_hwframe+0x49/0xbe
+ RIP: 0033:0x7f59a2b95f47
+
+Fixes: 8fcc4b5923af5 ("kvm: nVMX: Introduce KVM_CAP_NESTED_STATE")
+Cc: stable@vger.kernel.org
+Signed-off-by: Sean Christopherson <sean.j.christopherson@intel.com>
+Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/x86/kvm/x86.c | 3 +++
+ 1 file changed, 3 insertions(+)
+
+--- a/arch/x86/kvm/x86.c
++++ b/arch/x86/kvm/x86.c
+@@ -4117,6 +4117,7 @@ long kvm_arch_vcpu_ioctl(struct file *fi
+ case KVM_SET_NESTED_STATE: {
+ struct kvm_nested_state __user *user_kvm_nested_state = argp;
+ struct kvm_nested_state kvm_state;
++ int idx;
+
+ r = -EINVAL;
+ if (!kvm_x86_ops->set_nested_state)
+@@ -4138,7 +4139,9 @@ long kvm_arch_vcpu_ioctl(struct file *fi
+ if (kvm_state.flags == KVM_STATE_NESTED_RUN_PENDING)
+ break;
+
++ idx = srcu_read_lock(&vcpu->kvm->srcu);
+ r = kvm_x86_ops->set_nested_state(vcpu, user_kvm_nested_state, &kvm_state);
++ srcu_read_unlock(&vcpu->kvm->srcu, idx);
+ break;
+ }
+ default:
can-slcan-fix-use-after-free-read-in-slcan_open.patch
kernfs-fix-ino-wrap-around-detection.patch
jbd2-fix-possible-overflow-in-jbd2_log_space_left.patch
+drm-msm-fix-memleak-on-release.patch
+drm-i810-prevent-underflow-in-ioctl.patch
+arm64-dts-exynos-revert-remove-unneeded-address-space-mapping-for-soc-node.patch
+kvm-arm-arm64-vgic-don-t-rely-on-the-wrong-pending-table.patch
+kvm-x86-do-not-modify-masked-bits-of-shared-msrs.patch
+kvm-x86-fix-presentation-of-tsx-feature-in-arch_capabilities.patch
+kvm-x86-grab-kvm-s-srcu-lock-when-setting-nested-state.patch
+crypto-crypto4xx-fix-double-free-in-crypto4xx_destroy_sdr.patch
+crypto-atmel-aes-fix-iv-handling-when-req-nbytes-ivsize.patch
+crypto-af_alg-cast-ki_complete-ternary-op-to-int.patch
+crypto-geode-aes-switch-to-skcipher-for-cbc-aes-fallback.patch
+crypto-ccp-fix-uninitialized-list-head.patch
+crypto-ecdh-fix-big-endian-bug-in-ecc-library.patch
+crypto-user-fix-memory-leak-in-crypto_report.patch
+spi-atmel-fix-cs-high-support.patch
--- /dev/null
+From 7cbb16b2122c09f2ae393a1542fed628505b9da6 Mon Sep 17 00:00:00 2001
+From: Gregory CLEMENT <gregory.clement@bootlin.com>
+Date: Thu, 17 Oct 2019 16:18:41 +0200
+Subject: spi: atmel: Fix CS high support
+
+From: Gregory CLEMENT <gregory.clement@bootlin.com>
+
+commit 7cbb16b2122c09f2ae393a1542fed628505b9da6 upstream.
+
+Until a few years ago, this driver was only used with CS GPIO. The
+only exception is CS0 on AT91RM9200 which has to use internal CS. A
+limitation of the internal CS is that they don't support CS High.
+
+So by using the CS GPIO the CS high configuration was available except
+for the particular case CS0 on RM9200.
+
+When the support for the internal chip-select was added, the check of
+the CS high support was not updated. Due to this the driver accepts
+this configuration for all the SPI controller v2 (used by all SoCs
+excepting the AT91RM9200) whereas the hardware doesn't support it for
+infernal CS.
+
+This patch fixes the test to match the hardware capabilities.
+
+Fixes: 4820303480a1 ("spi: atmel: add support for the internal chip-select of the spi controller")
+Cc: <stable@vger.kernel.org>
+Signed-off-by: Gregory CLEMENT <gregory.clement@bootlin.com>
+Link: https://lore.kernel.org/r/20191017141846.7523-3-gregory.clement@bootlin.com
+Signed-off-by: Mark Brown <broonie@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/spi/spi-atmel.c | 6 ++----
+ 1 file changed, 2 insertions(+), 4 deletions(-)
+
+--- a/drivers/spi/spi-atmel.c
++++ b/drivers/spi/spi-atmel.c
+@@ -1193,10 +1193,8 @@ static int atmel_spi_setup(struct spi_de
+ as = spi_master_get_devdata(spi->master);
+
+ /* see notes above re chipselect */
+- if (!atmel_spi_is_v2(as)
+- && spi->chip_select == 0
+- && (spi->mode & SPI_CS_HIGH)) {
+- dev_dbg(&spi->dev, "setup: can't be active-high\n");
++ if (!as->use_cs_gpios && (spi->mode & SPI_CS_HIGH)) {
++ dev_warn(&spi->dev, "setup: non GPIO CS can't be active-high\n");
+ return -EINVAL;
+ }
+
projects / thirdparty / kernel / stable-queue.git / commitdiff
