Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754473AbbDRTCu (ORCPT ); Sat, 18 Apr 2015 15:02:50 -0400 Received: from mout.kundenserver.de ([212.227.126.187]:62682 "EHLO mout.kundenserver.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754097AbbDRTCp convert rfc822-to-8bit (ORCPT ); Sat, 18 Apr 2015 15:02:45 -0400 From: Arnd Bergmann To: Greg Kroah-Hartman Cc: Javier =?ISO-8859-1?Q?Gonz=E1lez?= , Jens Wiklander , Linux Kernel Mailing List , linux-arm-kernel@lists.infradead.org, devicetree@vger.kernel.org, Herbert Xu , tpmdd-devel@lists.sourceforge.net, Valentin Manea , jean-michel.delorme@st.com, emmanuel.michel@st.com Subject: Re: [RFC PATCH 2/2] tee: add OP-TEE driver Date: Sat, 18 Apr 2015 21:01:44 +0200 Message-ID: <4984990.7rV4p0zMYU@wuerfel> User-Agent: KMail/4.11.5 (Linux/3.16.0-10-generic; KDE/4.11.5; x86_64; ; ) In-Reply-To: <20150418184903.GB30508@kroah.com> References: <1429257057-7935-1-git-send-email-jens.wiklander@linaro.org> <20150418184903.GB30508@kroah.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8BIT Content-Type: text/plain; charset="iso-8859-1" X-Provags-ID: V03:K0:pF6VYKR0iVofWyXLGrgtP5z/XiDWYgZ688lv4QiaaTJDOIYiZGF bT0BWQTbwaQUFKk4Ly2nj56R/vqTu+NVAlD3ZpcSP0qF77Rat1Kv3D610eut7gW6+ch+sfn 1URP33saHk4HV2S2ud2wiePgwycZ91WClgseraSos5ele6Ry0v4Gs+9YKPao8N44FQVNPRf GE8ziD4UC5mrBsu1fqNfQ== X-UI-Out-Filterresults: notjunk:1; Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1432 Lines: 33 On Saturday 18 April 2015 20:49:03 Greg Kroah-Hartman wrote: > On Sat, Apr 18, 2015 at 11:36:53AM +0200, Javier Gonz?lez wrote: > > Hi, > > A: No. > Q: Should I include quotations after my reply? > > http://daringfireball.net/2007/07/on_top > > > We have discussed and implemented an in-kernel interface for the driver. > > However, we need to agree on that interface with the kernel submodules that > > can be interested in using it (e.g., IMA, keyring). We though it was easier > > to have a framework in place before taking this space. This makes sense > > since a TEE driver will be, as for today, mostly used by user space. > > applications. > > No, please provide a "real" solution, just providing a framework that no > one uses means that I get to delete it from the kernel tree the next > release, and I doubt you want that > > Please do all of the work here, as odds are, what you need in the end > will be different from what you have proposed here. I guess an alternative would be to remove all the unused infrastructure code and only provide a user space interface for the features that op_tee requires, but no optional user interfaces or in-kernel interfaces. Arnd -- 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/