On Mon, Mar 19, 2018 at 11:04:24AM +, Horia Geantă wrote:
>
> The only solution to avoid leaks in this case is to repeatedly DMA map & unmap
> the buffer.
> IOW, if one wants to load/save HW state in a buffer after an .update() and to
> instruct the crypto engine to do this operation, the follo
On 3/19/2018 11:25 AM, Herbert Xu wrote:
> On Mon, Mar 19, 2018 at 06:39:50AM +, Horia Geantă wrote:
>>
>> The fact that there can be multiple requests in parallel (for a given tfm)
>> is a
>> different topic.
>> Each request object has its state in its own state machine, independent from
>>
On Mon, Mar 19, 2018 at 06:39:50AM +, Horia Geantă wrote:
>
> The fact that there can be multiple requests in parallel (for a given tfm) is
> a
> different topic.
> Each request object has its state in its own state machine, independent from
> the
> other request objects.
> I assume this is c
On 3/16/2018 5:16 PM, Herbert Xu wrote:
> On Mon, Mar 05, 2018 at 12:39:45PM +0200, Horia Geantă wrote:
>> Even though it doesn't make too much sense, it is perfectly legal to:
>> - call .init() and then (as many times) .update()
>> - subseqently _not_ call any of .final(), .finup() or .export()
>
On Mon, Mar 05, 2018 at 12:39:45PM +0200, Horia Geantă wrote:
> Even though it doesn't make too much sense, it is perfectly legal to:
> - call .init() and then (as many times) .update()
> - subseqently _not_ call any of .final(), .finup() or .export()
Actually it makes perfect sense, because there
Even though it doesn't make too much sense, it is perfectly legal to:
- call .init() and then (as many times) .update()
- subseqently _not_ call any of .final(), .finup() or .export()
Update documentation since this is an important issue to consider
from resource management perspective.
Link: htt
