LF-3093-1 crypto: caam/jr - fix caam-keygen exit / clean-up

LF-3093-1 crypto: caam/jr - fix caam-keygen exit / clean-up

Introduction
===

Currently we are facing some limitations in the caam/jr module lifecycle.
There are some discussion in upstream:
Link: https://lore.kernel.org/linux-crypto/20190904023515.7107-13-andrew.smirnov@gmail.com
Link: https://lore.kernel.org/linux-crypto/20191105151353.6522-1-andrew.smirnov@gmail.com
but in the end it all seems to get down to implementations not being able
to gracefully unregister crypto algorithms from crypto API while there are
users / allocated tfms (cra_refcnt > 1).

[*] OTOH functionalities in caam/jr that don't interact with crypto API
(like Secure Memory or black keys / blobs generation) don't face this
limitation.

Issue at hand
===

When unloading the caam_jr module, the .remove callback for the last JR
device exits with -EBUSY (see "Introduction" above) and doesn't perform
the clean-up (crypto algorithms unregistering etc.).

One side effect of this is leeding to an oops, which occurs due to a
corruption in the linked list of "misc devices"
(drivers/char/misc.c - misc_list):
1. caam_jr module is unloaded without calling unregister_algs()->
caam_keygen_exit()->misc_deregister() for the last job ring device;
this leaves a dangling entry in the misc_list double-linked list
2. rng_core module is unloaded and calls misc_deregister(); this implies
removing the corresponding entry in the misc_list; while doing this the
dangling entry is accessed - which leads to an oops since the address is
no longer valid (address points to the caam_jr module address space,
but caam_jr has been previously unloaded).

Fix this by moving the clean-up of non-crypto related functionalities [*]
before crypto related ones.

Fixes: 3af836d4b311 ("MLK-24420-3 crypto: caam - add ioctl calls for black keys and blobs generation")
Signed-off-by: Horia Geantă <horia.geanta@nxp.com>
Reviewed-by: Gaurav Jain <gaurav.jain@nxp.com>