Re: [PATCH 3/3] hwrng: msm - Add support for prng v2

[Vinod <vkoul@kernel.org>]

Hi Stephan,

Thanks for the answers, they are helpful.

On 27-06-18, 08:13, Stephan Mueller wrote:
> > I have two follow up question on crypto:
> > 
> >  - If there a way to avoid using a global variable in driver to hold the
> >    pointer for driver memory? Looks like exynos driver does that.
> > 
> >    I understand that the crypto callback don't provide driver context as
> >    they copy the data structures passed in registration API, but a simpler
> >    way to get driver context would be desirable.
> 
> Sure the kernel crypto API can and has to maintain a per-instance data 
> structure.
> 
> See the crypto/drbg.c for instance.
> 
> static int drbg_kcapi_random(struct crypto_rng *tfm,
>                              const u8 *src, unsigned int slen,
>                              u8 *dst, unsigned int dlen)
> {
>         struct drbg_state *drbg = crypto_rng_ctx(tfm);
> 
> static int drbg_kcapi_seed(struct crypto_rng *tfm,
>                            const u8 *seed, unsigned int slen)
> {
>         struct drbg_state *drbg = crypto_rng_ctx(tfm);
> 
> The key is:
> 
>         alg->base.cra_ctxsize   = sizeof(struct drbg_state);
> 
> during initialization since the kernel crypto API allocates that buffer for 
> you and releases it during deallocation.

The difference here is that memory is allocated by crypto and driver has
no way to pass "it's" own data while doing registration. Ideally
registration should accept a pointer/long and pass that back on a
callbacks

Currently am doing bunch of initialization in .probe (platform driver)
and I think recommendation would be to move that to .cra_init, which seem
plausible but I don't have pdev to read hw_resource etc.. so would still
need to get that.

FWIW here is the code I wrote:
https://git.linaro.org/people/vinod.koul/kernel.git/commit/?h=topic/rng_v2&id=feb23a41afb0d4cf42a2825b84a43dbc9a49e8b9

-- 
~Vinod