On Tue, Jul 11, 2017 at 1:50 PM, Kamil Konieczny
<k.koniec...@partner.samsung.com> wrote:
> On 11.07.2017 12:30, Gilad Ben-Yossef wrote:
>> On Tue, Jul 11, 2017 at 10:52 AM, Kamil Konieczny
>> <k.koniec...@partner.samsung.com> wrote:
>>>
>>>
>>> I am writing crypto driver for hash MD5/SHA1/SHA256 on Exynos 4412,
>>> and I am facing some (minor?) difficulties. [...]
>
>>> So there is no [...] final method.
>>>
>>> It must be feeded with at least one message byte to produce hash.
>>>
>>> One more constrain is to process data in constant-sized chunks,
>>> here it is 64 bytes, the same as for AES block,
>>> i.e. it cannot stop and export state while in middle of block,
>>> example - if we feed 16 bytes, we must then feed 48 bytes
>>> to stop, but ideally we should feed it always 64 bytes. [...]
>>>
>>> Any suggestions ?
>>>
>>> Can i keep some bytes unfeeded from ahash_request
>>> and return -EINPROGRESS ?
>>> Should i set timer and copy rest bytes after some timeout,
>>> where no more requests are incoming ? Or not ? cause it is
>>> async mode ?
>>> can i wait for more requests for processing waiting one ?
>> Your two constraints are actually inter-related -
>>
>> If you can only feed the HW a constant size chunk, than indeed need to
>> keey bytes fed
>> to the driver the are below the chunk size in a software buffer, but
>> than you need the final()
>> method to feed these bytes (padded as needed) to the HW if they are
>> the last bytes
>>
>> Gilad
>
> HW will done padding
>
> I want to avoid memcpy iff possible for async hash

Why? you're talking about a copy of a single cache line at most.
That hardly seem worth the trouble.

Gilad

>
> --
> Best regards,
> Kamil Konieczny
> Samsung R&D Institute Poland



-- 
Gilad Ben-Yossef
Chief Coffee Drinker

"If you take a class in large-scale robotics, can you end up in a
situation where the homework eats your dog?"
 -- Jean-Baptiste Queru

Reply via email to