Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754622AbbFWMnI (ORCPT ); Tue, 23 Jun 2015 08:43:08 -0400 Received: from mga09.intel.com ([134.134.136.24]:25377 "EHLO mga09.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753844AbbFWMnG (ORCPT ); Tue, 23 Jun 2015 08:43:06 -0400 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.13,665,1427785200"; d="scan'208";a="748829895" Date: Tue, 23 Jun 2015 15:43:02 +0300 From: Jarkko Sakkinen To: Tejun Heo Cc: Jason Gunthorpe , Jarkko Sakkinen , tpmdd-devel@lists.sourceforge.net, linux-kernel@vger.kernel.org, peterhuewe@gmx.de, gregkh@linuxfoundation.org, Vivien Didelot , Guenter Roeck , NeilBrown Subject: Re: [PATCH v7 1/3] sysfs: added sysfs_link_entry_to_kobj() Message-ID: <20150623124302.GA22170@intel.com> References: <1434993894-5911-1-git-send-email-jarkko.sakkinen@linux.intel.com> <1434993894-5911-2-git-send-email-jarkko.sakkinen@linux.intel.com> <20150622173039.GA3710@mtj.duckdns.org> <20150622175253.GA28080@obsidianresearch.com> <20150622180154.GC3710@mtj.duckdns.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150622180154.GC3710@mtj.duckdns.org> Organization: Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo 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 Content-Length: 2585 Lines: 57 On Mon, Jun 22, 2015 at 02:01:54PM -0400, Tejun Heo wrote: > On Mon, Jun 22, 2015 at 11:52:53AM -0600, Jason Gunthorpe wrote: > > On Mon, Jun 22, 2015 at 01:30:39PM -0400, Tejun Heo wrote: > > > On Mon, Jun 22, 2015 at 08:24:50PM +0300, Jarkko Sakkinen wrote: > > > > Added a new function sysfs_link_group_to_kobj() that adds a symlink > > > > from attribute or group to a kobject. Exported kernfs_remove_by_name_ns > > > > in order to provide a way to remove such symlinks. > > > > > > > > Signed-off-by: Jarkko Sakkinen > > > > > > Hmmm... is this *really* necessary? If linking from the parent kobj > > > doesn't make a fundamental functional difference, I don't think this > > > is a good idea. If linking to the parent doesn't work, why doesn't > > > it? Shouldn't that already be a different kobj then? I'd really like > > > to keep groups as a dumb container of simple attrs. > > > > TPM is undergoing a migration of core attributes from the > > platform_device to the core's struct device. > > > > The only purpose of the symlink was to provide userspace > > compatability with the old location. > > Ah, yeah, that's painful. Can you please briefly explain why it > wasn't necessary before? Are you merging multiple devices into one? I've been working on for a while on TPM 2.0 protocol support and wanted to do things right from the beginning for TPM 2.0 level devices. The first thing was to introduce a device class for TPM devices (both 1.x and 2.0), which I did when the baseline support for TPM 2.0 landed in 4.0. The second is to introduce *necessary* sysfs attributes in the correct place so that they are created and destroyed race free. All sysfs attributes for TPM 1.x devices have been placed in the pdev directory. For major part of the attributes I decided not to add them at all for TPM 2.0 devices because they break all the conventions suggested in sysfs-rules.txt and more importantly you can acquire the data that they contain by using /dev/tpm0 and TPM protocol (either 1.x or 2.0). The PPI interface is necessary because it is used to take the ownership of the device. The solution that I'm presenting in this patch set is something that I just considered "least harm" when considering backwards compatibility and raciness. > Thanks. > > -- > tejun /Jarkko -- 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/