Received-SPF: pass (google.com: domain of linux-crypto-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
From:   Barry Song <song.bao.hua@hisilicon.com>
To:     <herbert@gondor.apana.org.au>, <davem@davemloft.net>
CC:     <linux-crypto@vger.kernel.org>, <linuxarm@huawei.com>,
        Barry Song <song.bao.hua@hisilicon.com>
Subject: [PATCH] crypto: acomp - search acomp with scomp backend in crypto_has_acomp
Date:   Thu, 30 Apr 2020 12:47:32 +1200
Message-ID: <20200430004732.24092-1-song.bao.hua@hisilicon.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 7BIT
Content-Type:   text/plain; charset=US-ASCII
Sender: linux-crypto-owner@vger.kernel.org
Precedence: bulk

users may call crypto_has_acomp to confirm the existence of acomp before using
crypto_acomp APIs. Right now, many of acomp have scomp backend, for example,
lz4, lzo, deflate etc. crypto_has_acomp will return false for them even though
they support acomp APIs.

One possible way to make has_acomp true for them is calling this APIs like
crypto_has_acomp("xxx", CRYPTO_ALG_TYPE_SCOMPRESS, 0);
But it looks quite weird.

Signed-off-by: Barry Song <song.bao.hua@hisilicon.com>
---
 include/crypto/acompress.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/crypto/acompress.h b/include/crypto/acompress.h
index d873f999b334..a7170848e6c2 100644
--- a/include/crypto/acompress.h
+++ b/include/crypto/acompress.h
@@ -156,7 +156,7 @@ static inline void crypto_free_acomp(struct crypto_acomp *tfm)
 static inline int crypto_has_acomp(const char *alg_name, u32 type, u32 mask)
 {
 	type &= ~CRYPTO_ALG_TYPE_MASK;
-	type |= CRYPTO_ALG_TYPE_ACOMPRESS;
+	type |= CRYPTO_ALG_TYPE_ACOMPRESS | CRYPTO_ALG_TYPE_SCOMPRESS;
 	mask |= CRYPTO_ALG_TYPE_MASK;
 
 	return crypto_has_alg(alg_name, type, mask);
-- 
2.23.0