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;
Message-ID: <b9931836dea5109a8a5aaa0a6e1abe558766d137.camel@gmx.de>
Subject: Re: [PATCH v2 3/6] crypto/realtek: hash algorithms
From:   Markus Stockhausen <markus.stockhausen@gmx.de>
To:     Herbert Xu <herbert@gondor.apana.org.au>
Cc:     linux-crypto@vger.kernel.org
Date:   Fri, 30 Dec 2022 09:38:21 +0100
In-Reply-To: <Y66ZgBx+hduj9S3K@gondor.apana.org.au>
References: <Y66ZgBx+hduj9S3K@gondor.apana.org.au>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
User-Agent: Evolution 3.46.2 (3.46.2-1.fc37) 
MIME-Version: 1.0
UI-OutboundReport: notjunk:1;M01:P0:rqb47yshblk=;CW7EuWlRai9knENEIE+kcqstIkV
 griGM2gasK9GELgOew8FX7c+QlEyBpEGkIVyiRPFTd1Teqi8EDZJ03ajkfSbkSuNusqj56MJZ
 EL8k9irKj/X6+4f6pYhsjewUgpIeDIpHeJFbPwqTqKmerxcuJqOf/DGHv7c/xbKSd2WNr9V4G
 BEH/uB/cWVPgj0AmK0zW9ycwipFKrsyBCn/lNV6YwrpYyHOdQbdUSspW63IRVNxkcaIxQpWHD
 ZA34r2H8M8ALw6Gwgx1P5dU+RfUVXnCmlxdWzBHk4PptMMuepT4ptXzpd8frbaHuEM8bhWD/N
 rLbAGdZzROM7YE94+bxWTKdWKcaM5wtDD5hYN5P0CNEM0sNu18WSgHvvBmk5AdZIRt6JPPtvW
 a7WFvGKVgreJZElLoSLgcICLqaguBIH36WfHgnxx/w26TodALiA6jnJgCiNTkU2e7D6NYdLr4
 4zvEgnIINpiCea/VfJ1vft7o73NnzROeyLlkMw1/A0Tc9rqtc0eatLK4r3XiF1x95C3Qp1PsP
 pRLuZ4UFYuzGzI4X/TrIYfb7E6mFJsXDCjP8TvEBlNoyYzKCwVYUgF+VlQuDtuwAWBu1RCBrA
 0scraZBaFJdZ8afpq1zN9H5t2gVwzrY3Vd4ivfMmXExl2OsuwwMH0m9DxX/5xk4UYuOHU1+n3
 j+RXYKgoEIyCK7MIofJLuiGxZTX4jci0i9HaqqyGT8YFvMLvXBOsEukTxlZsoI7prrfPknFxy
 WLUAfA+3TtwkZ9xdRkTXguUaNNUap0kwmN59xUThtivXmYgn8ea+ZHmjG9X8JyBa5hPqIPS/f
 DUxe9RQ8v1DLf8615GNsTyXX2cprAZes44Ot0qgA5kKG4pHkBTpj5TQDIQuca61Ns/RT3Q8Fo
 QtkeBE6RImvuzUa523PgRwdbvNn9ctRk6s1OKFO/RO9QV7waWw07kWqloHTUD7TOSPwhI97Ga
 NsW+Qw==
Precedence: bulk

Am Freitag, dem 30.12.2022 um 15:55 +0800 schrieb Herbert Xu:
> Markus Stockhausen <markus.stockhausen@gmx.de> wrote:
> >=20
> > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 /* Write back any uncommitted dat=
a to memory. */
> > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 if (hreq->buflen)
> > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0 dma_sync_single_for_device(cdev->dev,
> > virt_to_phys(hreq->buf),
> > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0 hreq->buflen,
> > DMA_TO_DEVICE);
>=20
> This is not how the DMA API works.=C2=A0 You must not do virt_to_phys.
> Instead use dma_map_single and dma_sync_* is not necessary unless
> you are using the mapping for something else.
>=20

DMA is totally new for me so thanks for the hint.=C2=A0

The simple thing we need to achieve is to flush the CPU caches so that
data becomes visible to the crypto engine. No other hardware specific
DMA commands needed for these SOCs as far as testing shows. I made use
of this because kernel for these devices is compiled with option
CONFIG_DMA_NONCOHERENT=3Dy and I found references to the function in the
caam crypto driver.

Can I just replace the calls with dma_map_single() or do I need other
initialization or cleanup calls?

Best regards.