On Tue, Jul 11, 2017 at 1:50 PM, Kamil Konieczny <k.konieczny@xxxxxxxxxxxxxxxxxxx> wrote: > On 11.07.2017 12:30, Gilad Ben-Yossef wrote: >> On Tue, Jul 11, 2017 at 10:52 AM, Kamil Konieczny >> <k.konieczny@xxxxxxxxxxxxxxxxxxx> 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
