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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, Nov 18, 2014 at 08:48:46PM +0000, James Hartley wrote:
>
> +struct img_hash_request_ctx {
> +	struct img_hash_dev	*hdev;
> +	u8 digest[SHA256_DIGEST_SIZE] __aligned(sizeof(u32));
> +	unsigned long		flags;
> +	size_t			digsize;
> +
> +	dma_addr_t		dma_addr;
> +	size_t			dma_ct;
> +
> +	/* sg root */
> +	struct scatterlist	*sgfirst;
> +	/* walk state */
> +	struct scatterlist	*sg;
> +	size_t			nents;
> +	size_t			offset;
> +	unsigned int		total;
> +	size_t			sent;
> +
> +	unsigned long		op;
> +
> +	size_t			bufcnt;
> +	u8 buffer[0] __aligned(sizeof(u32));
> +};

Unfortunately this is not consistent with our API since you're
not storing the non-final hash state in the request context.

It appears that you're finalising every request.  That means
you can only implement finup and digest.  With finup you'll
also need to be able to import a non-final hash state.  If the
hardware cannot do that then you can only implement digest.

Everything else would have to be done by a fallback driver.

So the question is can you obtain the non-final hash state from
the hardware and then reinsert it for the next operation?

Cheers,
-- 
Email: Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
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




[Index of Archives]     [Kernel]     [Gnu Classpath]     [Gnu Crypto]     [DM Crypt]     [Netfilter]     [Bugtraq]

  Powered by Linux