Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754553AbbDHOqJ (ORCPT ); Wed, 8 Apr 2015 10:46:09 -0400 Received: from mail-ig0-f174.google.com ([209.85.213.174]:35388 "EHLO mail-ig0-f174.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753666AbbDHOqG (ORCPT ); Wed, 8 Apr 2015 10:46:06 -0400 MIME-Version: 1.0 In-Reply-To: <20150408143831.GA30762@gondor.apana.org.au> References: <1428428070-17803-1-git-send-email-ddstreet@ieee.org> <1428428070-17803-10-git-send-email-ddstreet@ieee.org> <20150408141600.GA30338@gondor.apana.org.au> <20150408143831.GA30762@gondor.apana.org.au> From: Dan Streetman Date: Wed, 8 Apr 2015 10:45:45 -0400 X-Google-Sender-Auth: 9yMQRlw1LH-HUP2fwzUsqDEL5Rk Message-ID: Subject: Re: [PATCH 09/11] crypto: remove LZO fallback from crypto 842 To: Herbert Xu Cc: "David S. Miller" , Michael Ellerman , Benjamin Herrenschmidt , Paul Mackerras , Seth Jennings , Robert Jennings , linux-crypto@vger.kernel.org, "linuxppc-dev@lists.ozlabs.org" , linux-kernel Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2219 Lines: 52 On Wed, Apr 8, 2015 at 10:38 AM, Herbert Xu wrote: > On Wed, Apr 08, 2015 at 10:28:23AM -0400, Dan Streetman wrote: >> >> So, the sw implementation is only for decompression; there's no sw >> compression implementation in these patches. > > As a general rule we don't add any hardware implementation unless > there is a software implementation. The reason is that every new > algorithm creates an API (potentially a user-space API if the > algorithm can be exported via algif). But sometimes things slip > through. > > So I'm not going to immediately remove 842 but it would be nice > if we had a reference implementation so that if ever there were > another hardware 842 implmentation added then at least we have > something that we can judge against. Ok I'll see if I can include a sw compression implementation. > >> The hw 842 driver is currently at drivers/crypto/nx, and the >> crypto/842 driver just calls the hw driver (after correctly >> aligning/sizing the provided buffers to what the hw driver expects), >> and falls back to the sw decompression if the hw decompression fails >> (there is no compression fallback, a failure is reported to the >> caller). >> >> Is that setup ok? If users had to directly call the hw driver, >> instead of using the generic crypto_comp interface, it would >> complicate things, e.g. in zswap it only expects to call >> crypto_comp_compress()/decompress(), not call the 842 hw driver >> directly. > > I think the only thing that needs to happen for now is moving > crypto/842.c over to drivers/crypto/nx (perhaps merge it into > nx-842.c) so that it's obvious that this is not a generic > implementation. ah ok, so you mean it can still be a crypto_comp interface, just move its location and/or merge it into nx-842.c? > > Cheers, > -- > Email: Herbert Xu > Home Page: http://gondor.apana.org.au/~herbert/ > PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/