All of lore.kernel.org
 help / color / mirror / Atom feed
From: Antoine Tenart <atenart@kernel.org>
To: Aleksander Jan Bajkowski <olek2@wp.pl>
Cc: ansuelsmth@gmail.com, herbert@gondor.apana.org.au,
	davem@davemloft.net,  vschagen@icloud.com,
	linux-crypto@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] crypto: inside-secure/eip93 - unregister only available algorithm
Date: Mon, 5 Jan 2026 16:01:43 +0100	[thread overview]
Message-ID: <aVvRxqB6-Fdu0MXz@kwain> (raw)
In-Reply-To: <20251230235222.2113987-1-olek2@wp.pl>

On Wed, Dec 31, 2025 at 12:51:57AM +0100, Aleksander Jan Bajkowski wrote:
> EIP93 has an options register. This register indicates which crypto
> algorithms are implemented in silicon. Supported algorithms are
> registered on this basis. Unregister algorithms on the same basis.
> Currently, all algorithms are unregistered, even those not supported
> by HW. This results in panic on platforms that don't have all options
> implemented in silicon.
> 
> Fixes: 9739f5f93b78 ("crypto: eip93 - Add Inside Secure SafeXcel EIP-93 crypto engine support")
> Signed-off-by: Aleksander Jan Bajkowski <olek2@wp.pl>
> ---
>  .../crypto/inside-secure/eip93/eip93-main.c   | 107 ++++++++++--------
>  1 file changed, 61 insertions(+), 46 deletions(-)
> 
> diff --git a/drivers/crypto/inside-secure/eip93/eip93-main.c b/drivers/crypto/inside-secure/eip93/eip93-main.c
> index 3cdc3308dcac..dfac2b23e2d9 100644
> --- a/drivers/crypto/inside-secure/eip93/eip93-main.c
> +++ b/drivers/crypto/inside-secure/eip93/eip93-main.c
> @@ -77,11 +77,65 @@ inline void eip93_irq_clear(struct eip93_device *eip93, u32 mask)
>  	__raw_writel(mask, eip93->base + EIP93_REG_INT_CLR);
>  }
>  
> -static void eip93_unregister_algs(unsigned int i)
> +static int eip93_algo_is_supported(struct eip93_alg_template *eip93_algo,
> +				   u32 supported_algo_flags)
> +{
> +	u32 alg_flags = eip93_algo->flags;
> +
> +	if ((IS_DES(alg_flags) || IS_3DES(alg_flags)) &&
> +	    !(supported_algo_flags & EIP93_PE_OPTION_TDES))
> +		return 0;
> +
> +	if (IS_AES(alg_flags)) {
> +		if (!(supported_algo_flags & EIP93_PE_OPTION_AES))
> +			return 0;
> +
> +		if (!IS_HMAC(alg_flags)) {
> +			if (supported_algo_flags & EIP93_PE_OPTION_AES_KEY128)
> +				eip93_algo->alg.skcipher.max_keysize =
> +					AES_KEYSIZE_128;
> +
> +			if (supported_algo_flags & EIP93_PE_OPTION_AES_KEY192)
> +				eip93_algo->alg.skcipher.max_keysize =
> +					AES_KEYSIZE_192;
> +
> +			if (supported_algo_flags & EIP93_PE_OPTION_AES_KEY256)
> +				eip93_algo->alg.skcipher.max_keysize =
> +					AES_KEYSIZE_256;
> +
> +			if (IS_RFC3686(alg_flags))
> +				eip93_algo->alg.skcipher.max_keysize +=
> +					CTR_RFC3686_NONCE_SIZE;

Shouldn't the keysize assignment parts be kept in eip93_register_algs as
this has nothing to do with checking if an alg is supported and as
there's no point setting those (again) in the unregistration path?

> +		}
> +	}
> +
> +	if (IS_HASH_MD5(alg_flags) &&
> +	    !(supported_algo_flags & EIP93_PE_OPTION_MD5))
> +		return 0;
> +
> +	if (IS_HASH_SHA1(alg_flags) &&
> +	    !(supported_algo_flags & EIP93_PE_OPTION_SHA_1))
> +		return 0;
> +
> +	if (IS_HASH_SHA224(alg_flags) &&
> +	    !(supported_algo_flags & EIP93_PE_OPTION_SHA_224))
> +		return 0;
> +
> +	if (IS_HASH_SHA256(alg_flags) &&
> +	    !(supported_algo_flags & EIP93_PE_OPTION_SHA_256))
> +		return 0;
> +
> +	return 1;
> +}
> +
> +static void eip93_unregister_algs(u32 supported_algo_flags, unsigned int i)
>  {
>  	unsigned int j;
>  
>  	for (j = 0; j < i; j++) {
> +		if (!eip93_algo_is_supported(eip93_algs[j], supported_algo_flags))
> +			continue;
> +
>  		switch (eip93_algs[j]->type) {
>  		case EIP93_ALG_TYPE_SKCIPHER:
>  			crypto_unregister_skcipher(&eip93_algs[j]->alg.skcipher);
> @@ -102,51 +156,9 @@ static int eip93_register_algs(struct eip93_device *eip93, u32 supported_algo_fl
>  	int ret = 0;
>  
>  	for (i = 0; i < ARRAY_SIZE(eip93_algs); i++) {
> -		u32 alg_flags = eip93_algs[i]->flags;
> -
>  		eip93_algs[i]->eip93 = eip93;
>  
> -		if ((IS_DES(alg_flags) || IS_3DES(alg_flags)) &&
> -		    !(supported_algo_flags & EIP93_PE_OPTION_TDES))
> -			continue;
> -
> -		if (IS_AES(alg_flags)) {
> -			if (!(supported_algo_flags & EIP93_PE_OPTION_AES))
> -				continue;
> -
> -			if (!IS_HMAC(alg_flags)) {
> -				if (supported_algo_flags & EIP93_PE_OPTION_AES_KEY128)
> -					eip93_algs[i]->alg.skcipher.max_keysize =
> -						AES_KEYSIZE_128;
> -
> -				if (supported_algo_flags & EIP93_PE_OPTION_AES_KEY192)
> -					eip93_algs[i]->alg.skcipher.max_keysize =
> -						AES_KEYSIZE_192;
> -
> -				if (supported_algo_flags & EIP93_PE_OPTION_AES_KEY256)
> -					eip93_algs[i]->alg.skcipher.max_keysize =
> -						AES_KEYSIZE_256;
> -
> -				if (IS_RFC3686(alg_flags))
> -					eip93_algs[i]->alg.skcipher.max_keysize +=
> -						CTR_RFC3686_NONCE_SIZE;
> -			}
> -		}
> -
> -		if (IS_HASH_MD5(alg_flags) &&
> -		    !(supported_algo_flags & EIP93_PE_OPTION_MD5))
> -			continue;
> -
> -		if (IS_HASH_SHA1(alg_flags) &&
> -		    !(supported_algo_flags & EIP93_PE_OPTION_SHA_1))
> -			continue;
> -
> -		if (IS_HASH_SHA224(alg_flags) &&
> -		    !(supported_algo_flags & EIP93_PE_OPTION_SHA_224))
> -			continue;
> -
> -		if (IS_HASH_SHA256(alg_flags) &&
> -		    !(supported_algo_flags & EIP93_PE_OPTION_SHA_256))
> +		if (!eip93_algo_is_supported(eip93_algs[i], supported_algo_flags))
>  			continue;
>  
>  		switch (eip93_algs[i]->type) {
> @@ -167,7 +179,7 @@ static int eip93_register_algs(struct eip93_device *eip93, u32 supported_algo_fl
>  	return 0;
>  
>  fail:
> -	eip93_unregister_algs(i);
> +	eip93_unregister_algs(supported_algo_flags, i);
>  
>  	return ret;
>  }
> @@ -469,8 +481,11 @@ static int eip93_crypto_probe(struct platform_device *pdev)
>  static void eip93_crypto_remove(struct platform_device *pdev)
>  {
>  	struct eip93_device *eip93 = platform_get_drvdata(pdev);
> +	u32 algo_flags;
> +
> +	algo_flags = readl(eip93->base + EIP93_REG_PE_OPTION_1);
>  
> -	eip93_unregister_algs(ARRAY_SIZE(eip93_algs));
> +	eip93_unregister_algs(algo_flags, ARRAY_SIZE(eip93_algs));
>  	eip93_cleanup(eip93);
>  }
>  
> -- 
> 2.47.3
> 

  reply	other threads:[~2026-01-05 15:01 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-12-30 23:51 [PATCH] crypto: inside-secure/eip93 - unregister only available algorithm Aleksander Jan Bajkowski
2026-01-05 15:01 ` Antoine Tenart [this message]
2026-01-10 17:24   ` Aleksander Jan Bajkowski
  -- strict thread matches above, loose matches on Subject: below --
2026-01-11 13:20 Aleksander Jan Bajkowski
2026-01-12  8:56 ` Antoine Tenart
2026-01-31  2:48 ` Herbert Xu

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=aVvRxqB6-Fdu0MXz@kwain \
    --to=atenart@kernel.org \
    --cc=ansuelsmth@gmail.com \
    --cc=davem@davemloft.net \
    --cc=herbert@gondor.apana.org.au \
    --cc=linux-crypto@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=olek2@wp.pl \
    --cc=vschagen@icloud.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.