Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932252AbcDSRGy (ORCPT ); Tue, 19 Apr 2016 13:06:54 -0400 Received: from quartz.orcorp.ca ([184.70.90.242]:45519 "EHLO quartz.orcorp.ca" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932125AbcDSRGw (ORCPT ); Tue, 19 Apr 2016 13:06:52 -0400 Date: Tue, 19 Apr 2016 11:06:45 -0600 From: Jason Gunthorpe To: Stefan Berger Cc: Jarkko Sakkinen , tpmdd-devel@lists.sourceforge.net, linux-security-module@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v11 1/4] tpm: Remove all uses of drvdata from the TPM Core Message-ID: <20160419170645.GA20844@obsidianresearch.com> References: <1461000376-2888-1-git-send-email-stefanb@linux.vnet.ibm.com> <1461000376-2888-2-git-send-email-stefanb@linux.vnet.ibm.com> <20160419101214.GA11574@intel.com> <57160A26.5040805@linux.vnet.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <57160A26.5040805@linux.vnet.ibm.com> User-Agent: Mutt/1.5.23 (2014-03-12) X-Broken-Reverse-DNS: no host name found for IP address 10.0.0.160 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1662 Lines: 34 On Tue, Apr 19, 2016 at 06:36:22AM -0400, Stefan Berger wrote: > On 04/19/2016 06:12 AM, Jarkko Sakkinen wrote: > >On Mon, Apr 18, 2016 at 01:26:13PM -0400, Stefan Berger wrote: > >>From: Jason Gunthorpe > >> > >>The final thing preventing this was the way the sysfs files were > >>attached to the pdev. Follow the approach developed for ppi and move > >>the sysfs files to the chip->dev with symlinks from the pdev > >>for compatibility. Everything in the core now sanely uses container_of > >>to get the chip. > >Can you give me a quick recap why this patch was mandatory to make the > >patch set work? Which regression in the earlier versions of the patch > >set this fixes? > > The below patch removes usage of dev_get_drvdata() for retrieving the chip. > With Christophe's series dropping the priv field I now can use the drvdata > to store proxy_dev rather than re-introducing the priv field in the chip > structure. Besides that it doesn't seem necessary to use the drvdata field > to get from the chip to the device if a simple container_of can do it. More specifically, since the vtpm patches use a NULL parent, the approach of putting the sysfs files on the parent is no longer workable. The early vtpm patches simply moved the sysfs files to the tpm_chip when a parent is NULL, which is inconsistent for userspace. This also created a problem where drvdata on the chip now had to point back to the chip, meaning it became unusable for its new intended purpose. The fix is to make everything uniform and put the sysfs files in the correct place for all drivers (under the chip) and use symlinks for compat. Jason