From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S1753927AbbIKUKa (ORCPT <rfc822;w@1wt.eu>);
	Fri, 11 Sep 2015 16:10:30 -0400
Received: from mga03.intel.com ([134.134.136.65]:15101 "EHLO mga03.intel.com"
	rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
	id S1751696AbbIKUK2 (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
	Fri, 11 Sep 2015 16:10:28 -0400
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.17,513,1437462000"; 
   d="scan'208";a="767263515"
Message-ID: <1442002227.4322.45.camel@schen9-desk2.jf.intel.com>
Subject: Re: [PATCH 3/4] crypto: [sha] glue code for Intel SHA extensions
 optimized SHA1 & SHA256
From: Tim Chen <tim.c.chen@linux.intel.com>
To: David Miller <davem@davemloft.net>
Cc: smueller@chronox.de, herbert@gondor.apana.org.au, hpa@zytor.com,
        sean.m.gulley@intel.com, mouli_7982@yahoo.com, vinodh.gopal@intel.com,
        james.guilford@intel.com, wajdi.k.feghali@intel.com,
        jussi.kivilinna@iki.fi, linux-crypto@vger.kernel.org,
        linux-kernel@vger.kernel.org
Date: Fri, 11 Sep 2015 13:10:27 -0700
In-Reply-To: <20150911.121509.844598934515668336.davem@davemloft.net>
References: <1441929871.4322.15.camel@schen9-desk2.jf.intel.com>
	 <1671234.vBOzL28The@tauon.atsec.com>
	 <1441997372.4322.37.camel@schen9-desk2.jf.intel.com>
	 <20150911.121509.844598934515668336.davem@davemloft.net>
Content-Type: text/plain; charset="UTF-8"
X-Mailer: Evolution 3.8.5 (3.8.5-2.fc19) 
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On Fri, 2015-09-11 at 12:15 -0700, David Miller wrote:
> From: Tim Chen <tim.c.chen@linux.intel.com>
> Date: Fri, 11 Sep 2015 11:49:32 -0700
> 
> > Still, why would some kernel module specifically not want to 
> > use the fastest HW implementation, and explicitly ask for
> > a slower driver?
> 
> Temporary workaround if a bug is found.
> 
> There is really no reason to prevent the user from having this
> flexibility, and in return anyone can test any implementation
> their cpu can support.

Mmmm..., this is a restructuring of the algorithms within
the glue code into multiple drivers instead of one and exposing
them all.  It is a bit orthogonal to the intention of this
patch set.  I think it is better that I create a 
separate patch on the glue code on top of this patch set 
to implement this.

Herbert, do you agree with this approach?

Tim