From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 698E2C433FE for ; Mon, 28 Nov 2022 04:00:22 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id BD81D6B0072; Sun, 27 Nov 2022 23:00:21 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id B880F6B0073; Sun, 27 Nov 2022 23:00:21 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A76E16B0074; Sun, 27 Nov 2022 23:00:21 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id 95E356B0072 for ; Sun, 27 Nov 2022 23:00:21 -0500 (EST) Received: from smtpin24.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 6AEF91403B7 for ; Mon, 28 Nov 2022 04:00:21 +0000 (UTC) X-FDA: 80181498642.24.A97B4C7 Received: from formenos.hmeau.com (helcar.hmeau.com [216.24.177.18]) by imf27.hostedemail.com (Postfix) with ESMTP id 2FF9E40008 for ; Mon, 28 Nov 2022 04:00:19 +0000 (UTC) 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 1ozVJH-001OeH-TB; Mon, 28 Nov 2022 12:00:00 +0800 Received: by loth.rohan.me.apana.org.au (sSMTP sendmail emulation); Mon, 28 Nov 2022 11:59:59 +0800 Date: Mon, 28 Nov 2022 11:59:59 +0800 From: Herbert Xu To: Catalin Marinas Cc: Ard Biesheuvel , Will Deacon , Marc Zyngier , Arnd Bergmann , Greg Kroah-Hartman , Andrew Morton , Linus Torvalds , Linux Memory Management List , Linux ARM , Linux Kernel Mailing List , "David S. Miller" , Linux Crypto Mailing List Subject: Re: [v2 PATCH 2/9] crypto: api - Add crypto_tfm_ctx_dma Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1669608021; a=rsa-sha256; cv=none; b=kyOuLf2O4xc4IMqfjrrX1jSGA+h1Mr1S53Ki3LPJYlh8MhHyTrexMdIIKaTPfY7dtq8sKZ Kd79+TuEN8RBQsoIvhT/33cZ0U7V6jF9KLcn2WnP/VQZixE26s/RxVArwIToM3qQ1DokXx 7bnDrIGLmjEmprqz6D1i4pFJ2PXvCBs= ARC-Authentication-Results: i=1; imf27.hostedemail.com; dkim=none; spf=pass (imf27.hostedemail.com: domain of herbert@gondor.apana.org.au designates 216.24.177.18 as permitted sender) smtp.mailfrom=herbert@gondor.apana.org.au; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1669608021; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=ZvAHGzb+wBAH9dwZGyxqq1sLYM+Jye6NZrDj03zyPjI=; b=SYhBXbvCpyff2yhXpX5f9UywjunSy9fXdG029cytCgUHQDV6HtCZncpG4Nnh7ffD36igRt hjfznNHCXjJWc1kbaDnR6rMAdefARjqp5UjVYlA0r/JH4bUB1cuQcjK5bn9sACtYmr+jO2 S4cM+fOgRupcn24m7HPcAWz+4dC23jw= X-Stat-Signature: zdna47ortzw8n5xgjjf3pc38ba7ouz65 X-Rspamd-Queue-Id: 2FF9E40008 X-Rspam-User: Authentication-Results: imf27.hostedemail.com; dkim=none; spf=pass (imf27.hostedemail.com: domain of herbert@gondor.apana.org.au designates 216.24.177.18 as permitted sender) smtp.mailfrom=herbert@gondor.apana.org.au; dmarc=none X-Rspamd-Server: rspam10 X-HE-Tag: 1669608019-53430 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Fri, Nov 25, 2022 at 11:31:56AM +0000, Catalin Marinas wrote: > > Is the CRYPTO_DMA_PADDING used anywhere? I couldn't find it in this > series and I'd rather drop it, together with CRYPTO_DMA_ALIGN (see > below). Yes it's used by caam which needs it in a struct initialiser. > We have a generic dma_get_cache_alignment() function which currently is > either 1 or ARCH_DMA_MINALIGN, if the latter is defined. My plan is to > make eventually make this dynamic based on the actual cache line size > (on most arm64 systems it would be 64 rather than 128). So could you use > this instead of defining a CRYPTO_DMA_ALIGN? The only difference would > be that dma_get_cache_alignment() returns 1 rather than > ARCH_KMALLOC_MINALIGN if ARCH_DMA_MINALIGN is not defined, but I don't > think that's an issue. I'm trying to make the driver patches as robotic as possible. We could always improve upon this with driver-specific patches to change the struct initialiser to a run-time assignment to improve things further. Thanks, -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt