Hi,
I'm working on an ahash driver that supports CRC32C.
I saw that all existing CRC32C implementations (except blackfin) are
implementing shash interface, but ahash seems to be the correct choice
in our case.
On the other hand I saw that CRC32C test in testmgr.c tries to create
shash tfm for CRC32C and assumes that the CRC context is saved in first
4 bytes of the shash context.
When I implement CRC32C algorithm this part of the test fails.
How should I treat this failure? What is the reason for the requirement
that is tested in this scenario?
Thank you.
Zeev.
On 2/26/2013 7:11 PM, Zeev Zilberman wrote:
> Hi,
>
> I'm working on an ahash driver that supports CRC32C.
> I saw that all existing CRC32C implementations (except blackfin) are
> implementing shash interface, but ahash seems to be the correct choice
> in our case.
> On the other hand I saw that CRC32C test in testmgr.c tries to create
> shash tfm for CRC32C and assumes that the CRC context is saved in first
> 4 bytes of the shash context.
>
> When I implement CRC32C algorithm this part of the test fails.
>
> How should I treat this failure? What is the reason for the requirement
> that is tested in this scenario?
Same question here.
I've added a crc32c ahash implementation, and reverted commit:
8e3ee85e68c5d "crypto: crc32c - Test descriptor context format"
as a temporary workaround for the testmgr.c failure.
Thanks,
Horia