Received: by 2002:a05:6358:16cc:b0:ea:6187:17c9 with SMTP id r12csp2066908rwl; Fri, 6 Jan 2023 01:11:56 -0800 (PST) X-Google-Smtp-Source: AMrXdXt4XD3crEh85MbnsEfy04kzFwHx5NQLZXDUUqevHu0SNe68HY2SKcRKlZdsbkcZER8iXG1B X-Received: by 2002:a05:6a20:12ca:b0:ab:e8a7:6137 with SMTP id v10-20020a056a2012ca00b000abe8a76137mr78138737pzg.3.1672996316503; Fri, 06 Jan 2023 01:11:56 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1672996316; cv=none; d=google.com; s=arc-20160816; b=E+WA4LwkUmSTavnFgv8igNkzi6kFKxJL11/TlDD+tuLQhTKKg9sYlCIChdxQgKT7WT N7frSsCp+0NekcnH5L8EhogUqgPNn8sBPPab+kSiGtuyF2WD0HGh3jDXRqUVmns01SK5 2sA5Zb60vpmA8emka4J+FHKKoQfxauzr201FNGeyG+1SF94YErp80ZG10EhYWfklqXDj +qxwH4fHDAj2ZZoeM+piiBz//aUNhwSEuXcJhPxOVnvWCUrCTd8X2bG7zJlLBrXMRDQ6 8TxFv+6Asp9lAPjyGpmAzsRMYuH/M5pMGRU2F/gtJac5OylqsO0fku22NA7ilr329Rry 9kyw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :message-id:subject:cc:to:from:date; bh=GCSzjjzqISM7j/9ya71qr8A01tKcmgUkPqBWzZfSxiU=; b=W/ATVoqFFjde8IAit2WJkwbI8bmAHfSjdLg6O5xGJzg66DP8zkhxUYCnEpVmlpfeoa 2HSoiIYeIkCkn431RbSfyT/9iNZfx4FYL33saa1yXkBQ9bz0xvSnT80oeVrzOuMrEZ2/ 519Z5Tp7aeT2oL0BHPRxkPFM3aSri5DvDKLazMYsoBQMzdsG7AAru4ciaNhTMdVpYRIZ Ojxhr9bl5Kx9AkikY82B3GWLalPE7U/mTf3xKLQzz7rYO+1F9FWdLSjSiO2xHASiRcoD os/YnJ96Bw9TblU3SAl0XIHuZFEWp/7E3y1UszYijb867WTEutsU9R0XIT9B8+/mHlBw E8Jw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-crypto-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-crypto-owner@vger.kernel.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id n10-20020a635c4a000000b0047811809072si927156pgm.92.2023.01.06.01.11.42; Fri, 06 Jan 2023 01:11:56 -0800 (PST) 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; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-crypto-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-crypto-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229709AbjAFJDA (ORCPT + 99 others); Fri, 6 Jan 2023 04:03:00 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:36040 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231982AbjAFJC7 (ORCPT ); Fri, 6 Jan 2023 04:02:59 -0500 Received: from formenos.hmeau.com (helcar.hmeau.com [216.24.177.18]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 5FA3668C93 for ; Fri, 6 Jan 2023 01:02:57 -0800 (PST) Received: from loth.rohan.me.apana.org.au ([192.168.167.2]) by formenos.hmeau.com with smtp (Exim 4.94.2 #2 (Debian)) id 1pDico-00EVVG-Mf; Fri, 06 Jan 2023 17:02:55 +0800 Received: by loth.rohan.me.apana.org.au (sSMTP sendmail emulation); Fri, 06 Jan 2023 17:02:54 +0800 Date: Fri, 6 Jan 2023 17:02:54 +0800 From: Herbert Xu To: Markus Stockhausen Cc: linux-crypto@vger.kernel.org, markus.stockhausen@gmx.de Subject: Re: [PATCH v3 2/6] crypto/realtek: core functions Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20221231162525.416709-3-markus.stockhausen@gmx.de> X-Newsgroups: apana.lists.os.linux.cryptoapi X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,SPF_HELO_NONE, SPF_PASS autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-crypto@vger.kernel.org Markus Stockhausen wrote: > > +void rtcr_add_src_to_ring(struct rtcr_crypto_dev *cdev, int idx, void *vaddr, > + int blocklen, int totallen) > +{ > + dma_addr_t dma = cdev->src_dma + idx * RTCR_SRC_DESC_SIZE; > + struct rtcr_src_desc *src = &cdev->src_ring[idx]; > + > + src->len = totallen; > + src->paddr = virt_to_phys(vaddr); > + src->opmode = RTCR_SRC_OP_OWN_ASIC | RTCR_SRC_OP_CALC_EOR(idx) | blocklen; > + > + dma_sync_single_for_device(cdev->dev, dma, RTCR_SRC_DESC_SIZE, DMA_BIDIRECTIONAL); Why aren't there any calls to dma_sync_single_for_cpu if this is truly bidirectional? Cheers, -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt