Received-SPF: pass (google.com: domain of linux-crypto-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Tue, 10 Jan 2023 15:47:07 +0800
From:   Herbert Xu <herbert@gondor.apana.org.au>
To:     Markus Stockhausen <markus.stockhausen@gmx.de>
Cc:     linux-crypto@vger.kernel.org
Subject: Re: [PATCH v3 2/6] crypto/realtek: core functions
Message-ID: <Y70X+1alkLmnWBhR@gondor.apana.org.au>
References: <Y7fjvoc28CUza3qf@gondor.apana.org.au>
 <000f04f6ed4aef9bb4a67ae00fc259922f88090c.camel@gmx.de>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <000f04f6ed4aef9bb4a67ae00fc259922f88090c.camel@gmx.de>
Precedence: bulk

On Fri, Jan 06, 2023 at 05:17:16PM +0100, Markus Stockhausen wrote:
>
> Thanks, I need to check this again. CPU sets ownership bit in that
> descriptor to OWNED_BY_ASIC and after processing we expect that engine
> has set it back to OWNED_BY_CPU. So bidirectional operation is somehow
> needed.

For each bi-directional mapping, you must call

	dma_sync_single_for_cpu

before you read what the hardware has just written.  Then you make
your changes, and once you are done you do

	dma_sync_single_for_device

Note that you must ensure that the hardware does not modify the
memory area after you have called

	dma_sync_single_for_cpu

and before the next

	dma_sync_single_for_device

call.

Cheers,
-- 
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt