crypto: caam - enable hash api only on ARM platforms per default

Tests showed that ARMv8-A crypto extensions as implemented on the ARM
Cortex-A53 on the i.MX8M family of processors are substantially faster
than the same primitives offered by the CAAM.

Signed-off-by: Marco Felsch <m.felsch@pengutronix.de>
---
 drivers/crypto/caam/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

On 6/26/2024 6:57 PM, Marco Felsch wrote:
> Tests showed that ARMv8-A crypto extensions as implemented on the ARM
> Cortex-A53 on the i.MX8M family of processors are substantially faster
> than the same primitives offered by the CAAM.
> 
I disagree with compiling out the hash support.

If needed, algorithm priority could be changed - even at runtime,
using NETLINK_CRYPTO messages (needs CONFIG_CRYPTO_USER=y/m).

Thanks,
Horia

On Fri, Jul 05, 2024 at 09:39:19AM +0000, Horia Geanta wrote:
>
> I disagree with compiling out the hash support.
> 
> If needed, algorithm priority could be changed - even at runtime,
> using NETLINK_CRYPTO messages (needs CONFIG_CRYPTO_USER=y/m).

We should change the default priority.

Thanks,

On 24-07-05, Herbert Xu wrote:
> On Fri, Jul 05, 2024 at 09:39:19AM +0000, Horia Geanta wrote:
> >
> > I disagree with compiling out the hash support.

We don't compile it out, we just don't set the default=y since on ARMv8
it's not required.

> > If needed, algorithm priority could be changed - even at runtime,
> > using NETLINK_CRYPTO messages (needs CONFIG_CRYPTO_USER=y/m).
> 
> We should change the default priority.

We had an patch exactly doing this but depending on the SoC the default
prio may valid since the CAAM is used on ARMv7 and ARMv8 NXP SoCs. To
not cause any regression we went this way.

Regards,
  Marco

> 
> Thanks,
> -- 
> Email: Herbert Xu <herbert@gondor.apana.org.au>
> Home Page: http://gondor.apana.org.au/~herbert/
> PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
>

On Tue, Jul 09, 2024 at 10:54:54AM +0200, Marco Felsch wrote:
>
> We had an patch exactly doing this but depending on the SoC the default
> prio may valid since the CAAM is used on ARMv7 and ARMv8 NXP SoCs. To
> not cause any regression we went this way.

I don't understand.  Why not just set the priority depending on
IS_ENABLED(CONFIG_ARM)? That way it's strictly better than the
Kconfig patch:

1) If the driver is indeed slower then you'd have achieved the same
result of preferring the non-driver algorithm.

2) If the driver ends up being faster then at least the admin can
adjust the priorities.

Or perhaps your Kconfig option should set the priority.

Cheers,

On 24-07-10, Herbert Xu wrote:
> On Tue, Jul 09, 2024 at 10:54:54AM +0200, Marco Felsch wrote:
> >
> > We had an patch exactly doing this but depending on the SoC the default
> > prio may valid since the CAAM is used on ARMv7 and ARMv8 NXP SoCs. To
> > not cause any regression we went this way.
> 
> I don't understand.  Why not just set the priority depending on
> IS_ENABLED(CONFIG_ARM)? 

Argh.. you're right. I had something other in my mind, sry.

> That way it's strictly better than the Kconfig patch:
> 
> 1) If the driver is indeed slower then you'd have achieved the same
> result of preferring the non-driver algorithm.
> 
> 2) If the driver ends up being faster then at least the admin can
> adjust the priorities.
> 
> Or perhaps your Kconfig option should set the priority.

NACK since no admin knows the prios. I will go with the "IS_ENABLED"
solution, thank you!

Regards,
  Marco

> Cheers,
> -- 
> Email: Herbert Xu <herbert@gondor.apana.org.au>
> Home Page: http://gondor.apana.org.au/~herbert/
> PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
>