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
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
