From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754464AbbDRUuf (ORCPT ); Sat, 18 Apr 2015 16:50:35 -0400 Received: from pandora.arm.linux.org.uk ([78.32.30.218]:38843 "EHLO pandora.arm.linux.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753168AbbDRUud (ORCPT ); Sat, 18 Apr 2015 16:50:33 -0400 Date: Sat, 18 Apr 2015 21:50:19 +0100 From: Russell King - ARM Linux To: Greg Kroah-Hartman Cc: Jens Wiklander , valentin.manea@huawei.com, devicetree@vger.kernel.org, javier@javigon.com, emmanuel.michel@st.com, Herbert Xu , Arnd Bergmann , linux-kernel@vger.kernel.org, jean-michel.delorme@st.com, tpmdd-devel@lists.sourceforge.net, linux-arm-kernel@lists.infradead.org Subject: Re: [RFC PATCH 1/2] tee: generic TEE subsystem Message-ID: <20150418205019.GL12732@n2100.arm.linux.org.uk> References: <1429257057-7935-1-git-send-email-jens.wiklander@linaro.org> <1429257057-7935-2-git-send-email-jens.wiklander@linaro.org> <20150418085712.GB29858@kroah.com> <20150418090420.GG12732@n2100.arm.linux.org.uk> <20150418184713.GA30508@kroah.com> <20150418190224.GK12732@n2100.arm.linux.org.uk> <20150418203716.GC1347@kroah.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150418203716.GC1347@kroah.com> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sat, Apr 18, 2015 at 10:37:16PM +0200, Greg Kroah-Hartman wrote: > On Sat, Apr 18, 2015 at 08:02:24PM +0100, Russell King - ARM Linux wrote: > > On Sat, Apr 18, 2015 at 08:47:13PM +0200, Greg Kroah-Hartman wrote: > > > On Sat, Apr 18, 2015 at 10:04:20AM +0100, Russell King - ARM Linux wrote: > > > > On Sat, Apr 18, 2015 at 10:57:12AM +0200, Greg Kroah-Hartman wrote: > > > > > On Fri, Apr 17, 2015 at 09:50:56AM +0200, Jens Wiklander wrote: > > > > > > +struct tee_device { > > > > > > + char name[TEE_MAX_DEV_NAME_LEN]; > > > > > > + const struct tee_desc *desc; > > > > > > + struct device *dev; > > > > > > > > > > No, please embed the device in your structure, don't have a pointer to > > > > > it. > > > > > > > > Greg, "dev" here is not a locally allocated device, but the parent device. > > > > It's actually the same as struct tee_device.miscdev.parent, which could be > > > > used instead and this member deleted. > > > > > > A miscdev doesn't need to have a "parent", it's just there to provide a > > > character device node to userspace, not to represent a "device that you > > > can do things with in the heirachy". > > > > > > If you really want that, then use a real 'struct device' as should be > > > done here. Have just a pointer to a misc device, that is meant to be > > > dynamic. > > > > Let's rewind. > > > > You are saying that "struct device *dev;" should be "struct device dev;" > > Yes. > > > I'm saying that you are mis-interpreting in your review what _that_ is. > > Probably, I really have no idea what it is anymore. What it _should_ be > is the thing that controls the lifecycle of the structure. Do not use a > miscdevice for that, it will not work, as the TPM developers found out > the hard way. I _really_ don't understand what you're going on about. The "struct device *dev" is a pointer to the struct device corresponding to the _device_ which is being probed and the tee device is being registered for - in the case of the submitted code, that is the struct device embedded in the platform device. This is a /really/ standard thing to do in drivers - saving a pointer to the struct device which the driver is responsible for. So why should this pointer become a struct device itself? Greg, I think you have performed a disservice by poorly reviewing the driver, and giving _incorrect_ comments. Please can you have another look at both patches together and provide a better review. Thanks. Second point _against_ embedding a struct device here - a struct device is exposed to userspace. Why expose this to userspace - we have other ways to manage the lifetime of data structures, such as krefs, which are not exposed to userspace. What's wrong with using a kref to control the lifetime of this structure? -- FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up according to speedtest.net.