Received: by 2002:a6b:500f:0:0:0:0:0 with SMTP id e15csp548885iob; Wed, 11 May 2022 22:18:23 -0700 (PDT) X-Google-Smtp-Source: ABdhPJz1O9UVy9tx/kphWlmgKnnBxQCiSdMXXTlGYibbhfJ7eqcYfgHwLLlDHBt7s2E6lYlDu+iS X-Received: by 2002:a17:90a:bd95:b0:1d9:6735:e9ef with SMTP id z21-20020a17090abd9500b001d96735e9efmr9032951pjr.157.1652332702944; Wed, 11 May 2022 22:18:22 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1652332702; cv=none; d=google.com; s=arc-20160816; b=Z3zktAd0TCADSkYmPaCTZT0tIvwk/k1kULXmJ6Db5aN0x0Z+ldoD1eny+4VCeHYiJU /ZL89N+RNKOrs1d5dAKJYkesMCNUAak0v9uDCP+1kW+08DJhDSHHQqNLLoRCQLxCxXc+ INEUlprwLu8NlYBKdLv+22VxDDNkIYal8TL7VAXe/wNd7sCb4NRHNAWUQUnxMf3LfZYs OSvRXNzuUD6TNDMvlGtwWnZ/D292QJZp4NXNzRz+POoP//k/S+RYrv2YW3WGB4QYd/8U 47k84vEoOBtxvN+7y2HcxARTCft45lwD6yVUiAoxq3SunDk9ed35LLofS2CMzOBt1wpQ xgxg== 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 :references:message-id:subject:cc:to:from:date; bh=tQzdB74GzQ0uwfZiro1KJdUEQIjxu1ijIMttuAdVwlI=; b=GETfH+FcpObp2I8eTWdq7Of2RNZ5O+Oaju05nYZgki9SiOL8vFF32obANqUdCjslND q6rt8DUGw0CMEi4K9aQPKAhw1sW0Slp1xescj27QDZ8Xv457gecHRV++zs6u3zHZ4DAl Pc5yTXgUlHinzDWOrOYR2eQamOB9oZeJROV+DfmILhUN6d882Pj/ubZaMG224SzA7tLC mOLtfMro90JpJXptc6hfRPfaTnKQw2BxQvII9R52LMPhXE1A00CjGkY3PKgonpKyzDPt avTSZYOnKhNixSh54DvDXJzD8T7n4fKAaFJ6eV8/eq+m3qfG6SW/0QG8duoHuNIwluWP s6gw== 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 o23-20020a17090aac1700b001dcbf73882bsi2150101pjq.16.2022.05.11.22.17.52; Wed, 11 May 2022 22:18:22 -0700 (PDT) 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 S1345362AbiELD5l (ORCPT + 99 others); Wed, 11 May 2022 23:57:41 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:41922 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1345368AbiELD5g (ORCPT ); Wed, 11 May 2022 23:57:36 -0400 Received: from fornost.hmeau.com (helcar.hmeau.com [216.24.177.18]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id BE11D26544; Wed, 11 May 2022 20:57:32 -0700 (PDT) Received: from gwarestrin.arnor.me.apana.org.au ([192.168.103.7]) by fornost.hmeau.com with smtp (Exim 4.94.2 #2 (Debian)) id 1nozwj-00CmlI-4v; Thu, 12 May 2022 13:57:02 +1000 Received: by gwarestrin.arnor.me.apana.org.au (sSMTP sendmail emulation); Thu, 12 May 2022 11:57:01 +0800 Date: Thu, 12 May 2022 11:57:01 +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: [RFC PATCH 2/7] 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: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,SPF_HELO_NONE, SPF_PASS,T_SCC_BODY_TEXT_LINE 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 On Tue, May 10, 2022 at 06:10:34PM +0100, Catalin Marinas wrote: > > Is there a case where a driver needs the minimum alignment between > ARCH_DMA_MINALIGN and crypto_tfm_alg_alignmask()+1? Maybe for platforms > where ARCH_DMA_MINALIGN is 8 (fully coherent) but the device's bus > master alignment requirements are higher. Yes, for example on x86 aesni requires 16-byte alignment. > My plan is to have ARCH_DMA_MINALIGN always defined but potentially > higher than ARCH_KMALLOC_MINALIGN on specific architectures. I think > crypto_tfm_ctx_dma() should use ARCH_KMALLOC_MINALIGN (and no #ifdefs) > until I get my patches sorted and I'll replace it with ARCH_DMA_MINALIGN > once it's defined globally (still no #ifdefs). Currently in mainline > it's ARCH_KMALLOC_MINALIGN that gives the static DMA alignment. > > With the explicit crypto_tfm_ctx_dma(), can CRYPTO_MINALIGN_ATTR be > dropped entirely? This may be beneficial in reducing the structure size > when no DMA is required. We always need CRYPTO_MINALIGN to reflect what alignment kmalloc guarantees. It is used to minimise the amount of extra padding for users such aesni. This shouldn't have any impact on your plans though as once the drivers in question switch over to the DMA helpers you can safely lower ARCH_KMALLOC_MINALIGN. Cheers, -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt