On Fri, Nov 14, 2014 at 11:55 PM, Corentin LABBE
<clabbe.montjoie@xxxxxxxxx> wrote:
> 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)
That sounds good to me.
--
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
