From patchwork Mon Aug 27 11:02:41 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Ard Biesheuvel X-Patchwork-Id: 10576953 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork-2.web.codeaurora.org (Postfix) with ESMTP id CD58D1803 for ; Mon, 27 Aug 2018 11:03:28 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id BEC8F29523 for ; Mon, 27 Aug 2018 11:03:28 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id B3C08295DD; Mon, 27 Aug 2018 11:03:28 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-8.0 required=2.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,RCVD_IN_DNSWL_HI autolearn=ham version=3.3.1 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 5A23B29608 for ; Mon, 27 Aug 2018 11:03:28 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727056AbeH0OtM (ORCPT ); Mon, 27 Aug 2018 10:49:12 -0400 Received: from mail-ed1-f65.google.com ([209.85.208.65]:45041 "EHLO mail-ed1-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726785AbeH0OtM (ORCPT ); Mon, 27 Aug 2018 10:49:12 -0400 Received: by mail-ed1-f65.google.com with SMTP id s10-v6so10115820edb.11 for ; Mon, 27 Aug 2018 04:03:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=from:to:cc:subject:date:message-id; bh=KZpXutJD8TJDNiGk/rbW/vWe21LI0Ft8rx8Dmxx88Jw=; b=B9H/00l/A38AZ0GnJJ6RMEqfOIDUf6edSpUR80T1y7vw45Pd8sA18wSG5Pu+5f4z9n V7OQKazV/yxfFJREddZrMDdWu6NoMIFHGn/fnbBSbEBO5V+Q3TcNS8p6uJQcRl8HXrkc 8kkZ+CKQe4s/x4sQptQhsxxNAAZDg6CWNB2No= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id; bh=KZpXutJD8TJDNiGk/rbW/vWe21LI0Ft8rx8Dmxx88Jw=; b=t3XnB5UBKCkZGQ3upj8jvmUrNx26mGCagVYHXK5DyEFpIme/XRgbOicKmrAT4/vmSJ 5Ys0c4s5TZMLSrP+jI22CQwkeyMGo1Ks1PJ7zkqgMhNTpG/vvyNLt0p2u3so48CvYkYd IMsqJw1IjRVe1XPtpWueRb25FGziBy0yyqqxE/WPKDiNZRI88W26X06jLr2QdyquZQ0A Xm8uAcpkuFXhxdq/g+sEjfCVDiXkfQz9Rne5cezpHScvAijzWZC9rr94gNZ0u8N47YTY uFwBfVt+ZuAYrTAEoN+bA7tPmJAW0oACKcNN2+cr0+XxwziueybAE2IWjc/cySpPgONc y9/A== X-Gm-Message-State: APzg51Bympyqg1vFpSpxnWqlSCKGbr6pekTOcTNNjG4lwu7X0gjrEO7s vBBYFWQ3aLfPvFIQ+qkOkGAeUg== X-Google-Smtp-Source: ANB0VdZ15BArf225FMwUl6lV/s5gWxygzNw8Vk/gEodEtfkTLgjcWuHbP9Silo4/bUKSYv9Fz42phA== X-Received: by 2002:a50:b003:: with SMTP id i3-v6mr16010146edd.120.1535367779989; Mon, 27 Aug 2018 04:02:59 -0700 (PDT) Received: from rev02.home ([2a02:a212:9283:9800:24b9:e2d6:9acc:50dd]) by smtp.gmail.com with ESMTPSA id r2-v6sm3114344eda.89.2018.08.27.04.02.58 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 27 Aug 2018 04:02:59 -0700 (PDT) From: Ard Biesheuvel To: linux-arm-kernel@lists.infradead.org, linux-crypto@vger.kernel.org Cc: will.deacon@arm.com, catalin.marinas@arm.com, herbert@gondor.apana.org.au, ebiggers@google.com, suzuki.poulose@arm.com, linux-kernel@vger.kernel.org, Ard Biesheuvel Subject: [PATCH 0/4] arm64: wire CRC32 instructions into core crc32 routines Date: Mon, 27 Aug 2018 13:02:41 +0200 Message-Id: <20180827110245.14812-1-ard.biesheuvel@linaro.org> X-Mailer: git-send-email 2.18.0 Sender: linux-crypto-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-crypto@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP There are many crc32 users in the kernel that call the library routine rather than the crypto API wrapper, and so none of these callers use the accelerated arm64 instructions when available. While this is not known to cause performance issues, calling a table based time variant implementation with a non-negligible D-cache footprint (8 KB) is wasteful in any case, and now that the crc32 instructions have been made mandatory in the architecture, let's wire them up into the core crc routines. This also means that they will be exposed to the crypto API via the generic CRC32 driver, and so we can remove the scalar routines from the crypto API driver. This leaves the PMULL code, which will only be useful on systems that implement 64x64 PMULL but not the CRC32 instructions. Given that no such systems are known to exist, this driver is removed entirely in patch #4. Ard Biesheuvel (4): lib/crc32: make core crc32() routines weak so they can be overridden arm64: cpufeature: add feature for CRC32 instructions arm64/lib: add accelerated crc32 routines crypto: arm64/crc32 - remove PMULL based CRC32 driver arch/arm64/Kconfig | 1 + arch/arm64/configs/defconfig | 1 - arch/arm64/crypto/Kconfig | 5 - arch/arm64/crypto/Makefile | 3 - arch/arm64/crypto/crc32-ce-core.S | 287 -------------------- arch/arm64/crypto/crc32-ce-glue.c | 244 ----------------- arch/arm64/include/asm/cpucaps.h | 3 +- arch/arm64/kernel/cpufeature.c | 9 + arch/arm64/lib/Makefile | 2 + arch/arm64/lib/crc32.S | 60 ++++ lib/crc32.c | 11 +- 11 files changed, 81 insertions(+), 545 deletions(-) delete mode 100644 arch/arm64/crypto/crc32-ce-core.S delete mode 100644 arch/arm64/crypto/crc32-ce-glue.c create mode 100644 arch/arm64/lib/crc32.S