Re: [PATCH 1/2] crypto: Add Imagination Technologies hw hash accelerator

[Corentin LABBE <clabbe.montjoie@gmail.com>]

Le 15/11/2014 00:59, Andrew Bresticker a écrit :
> Hi James,
> 
>> +
>> +struct img_hash_drv {
>> +       struct list_head dev_list;
>> +       spinlock_t lock;
>> +};
>> +
>> +static struct img_hash_drv img_hash = {
>> +       .dev_list = LIST_HEAD_INIT(img_hash.dev_list),
>> +       .lock = __SPIN_LOCK_UNLOCKED(img_hash.lock),
>> +};
> 
> It looks like the only purpose of this list is to get the
> corresponding struct img_hash_dev in img_hash_init().  If there's
> never going to be multiple instances within an SoC, perhaps you could
> just use a global?  Otherwise, you could do something like the
> qualcomm driver, see drivers/crypto/qce/sha.c.  It looks like there is
> some precedent for this device list though...
> 

I don't understand, you propose to use a global, something that lots of people want to be removed in my driver.
It is not better than this global list.

I have the fealing that there no good way to get a pointer to a driver structure inside the cryptoAPI.
What to you think about adding a void *data in struct crypto_alg

Before registering an alg you could do:
mv_aes_alg_ecb.data = myprivatedriverdata;
ret = crypto_register_alg(&mv_aes_alg_ecb);

and then get it via
struct crypto_priv *cp = req->base.tfm->__crt_alg->data;
(a function will be better than that)

So what is the recommended way to get driver structure inside the cryptoAPI function (init/udpate/final)?

Regards