crypto: Add Imagination Technologies hw hash accelerator
A message that is not in the archive (sent off-list or not yet received): [email protected]
Quoted 38 lines · James Hartley
Quoted 17 lines
Quoted 17 lines
(quoted diff) +16
-0+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;Quoted 8 lines
Review
Quoted 6 lines
(quoted diff) +6
-0+ 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
Quoted 3 lines
non-final hash state in the request context.
It appears that you're finalising every request. That means you can
only
Quoted 1 line
implement finup and digest. With finup you'll also need to be able
to import
Quoted 1 line
a non-final hash state. If the hardware cannot do that then you can
only
Quoted 4 lines
implement digest.
Everything else would have to be done by a fallback driver.
Quoted 8 lines
Quoted 1 line
So the question is can you obtain the non-final hash state from the
hardware
Quoted 1 line
and then reinsert it for the next operation?
I've looked into this and unfortunately the hardware cannot do that. I'll spend some time looking into what this means (I'm not the author of the driver, so will need to become a bit more familiar with it).
Hi Herbert,
Firstly apologies that there have been quite a few weeks since we last discussed this driver!
I understand that because the HW does not support an initial hash state, I can only implement digest, and not init, update and final. You mentioned that I would have to do everything else using a fallback driver - but I'm not clear on:
- If it is mandatory to impement a fallback driver (because the potential users of the framework would not know only digest is supported?)
- or can I just remove the support for init update and final?
If I need to implement fallback drivers, would the Niagra2 SPU driver be a good reference http://lxr.free-electrons.com/source/drivers/crypto/n2_core.c ?
Thanks,
James
Herbert Xu
maintainerQuoted 4 lines · James Hartley
- If it is mandatory to impement a fallback driver (because the potential users of the framework would not know only digest is supported?)
Yes it is mandatory.
Quoted 3 lines
If I need to implement fallback drivers, would the Niagra2 SPU driver be a good reference
http://lxr.free-electrons.com/source/drivers/crypto/n2_core.c ?
Yes it's a good example.
Cheers,
Signature · 3 lines
Email: Herbert Xu <[email protected]> Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Quoted 4 lines · Herbert Xu
Quoted 3 lines · James Hartley
- If it is mandatory to impement a fallback driver (because the potential users of the framework would not know only digest is supported?)
Quoted 8 lines
Yes it is mandatory.
Quoted 3 lines
If I need to implement fallback drivers, would the Niagra2 SPU driver be a good reference
http://lxr.free-electrons.com/source/drivers/crypto/n2_core.c ?Yes it's a good example.
Cheers,
Great, I'll prepare a new patchset. For the previous patches I did some basic testing using the built in crypto manager tests, but these all pass without the fallback implemented - is there another more appropriate set of tests that you would recommend I use to verify that my implementation is correct?
Thanks,
James