From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.3 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_PASS,URIBL_BLOCKED,USER_AGENT_MUTT autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 20AC4ECDE32 for ; Wed, 17 Oct 2018 14:53:28 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id D84CB214DD for ; Wed, 17 Oct 2018 14:53:27 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org D84CB214DD Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=linux.intel.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727715AbeJQWt3 (ORCPT ); Wed, 17 Oct 2018 18:49:29 -0400 Received: from mga01.intel.com ([192.55.52.88]:17631 "EHLO mga01.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727000AbeJQWt3 (ORCPT ); Wed, 17 Oct 2018 18:49:29 -0400 X-Amp-Result: UNKNOWN X-Amp-Original-Verdict: FILE UNKNOWN X-Amp-File-Uploaded: False Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by fmsmga101.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 17 Oct 2018 07:53:21 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.54,392,1534834800"; d="scan'208";a="100019606" Received: from kuha.fi.intel.com ([10.237.72.189]) by fmsmga001.fm.intel.com with SMTP; 17 Oct 2018 07:53:18 -0700 Received: by kuha.fi.intel.com (sSMTP sendmail emulation); Wed, 17 Oct 2018 17:53:18 +0300 Date: Wed, 17 Oct 2018 17:53:17 +0300 From: Heikki Krogerus To: Andy Shevchenko Cc: Dmitry Torokhov , Linus Walleij , "Rafael J. Wysocki" , Andy Shevchenko , Mika Westerberg , Linux Kernel Mailing List , ACPI Devel Maling List Subject: Re: [RFC PATCH 0/5] device property: Introducing software nodes Message-ID: <20181017145317.GA14912@kuha.fi.intel.com> References: <20181012113934.29942-1-heikki.krogerus@linux.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.2 (2017-12-15) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Oct 16, 2018 at 05:35:50PM +0300, Andy Shevchenko wrote: > On Fri, Oct 12, 2018 at 2:41 PM Heikki Krogerus > wrote: > > > > Hi guys, > > > > To continue the discussion started by Dmitry [1], this is my proposal > > that I mentioned in my last mail. In short, the idea is that instead > > of trying to extend the support for the currently used struct > > property_set, I'm proposing that we introduce a completely new, > > independent type of fwnode, and replace the struct property_set with > > it. I'm calling the type "software node" here. > > > > The reason for a complete separation of the software nodes from the > > generic property handling code is the need to be able to create the > > nodes independently from the devices that they are bind to. > > > > The way this works is that every node that is created will have a > > kobject registered. That will take care the ref counting for us, and > > also allow us to for example display the properties in sysfs. > > > > There are a few more details in patch 3/5 about the software nodes in > > the commit message. > > > > [1] https://lkml.org/lkml/2018/9/17/1067 > > In private discussion I brought a concern that we exposed properties > as a part of ABI, but at the same time we have not strict rules which > might lead to ambiguous reading, e.g. there is no type exported and > thus no possibility to tell what kind of property it is. > > Examples: > 1. 0x1 and 0x1 ??? are they of the same type? > 2. 0x1 ??? is it an array or single value? > 3. 0x12345678 ??? is it string or hex? > 4. 25 ??? is it hex or decimal? This is mostly a note to self, but also to let everybody know: After thinking about this a bit more I realised that the user space has to know what the property it is reading contains. An array of integers can actually be a string in reality, just like a string may contain an integer value(s). String or string array could describe a data structure, or even supply the values for one. In reality the type of the property, or the fact that it's an array or not, do not help at all to determine the content of the property. So the user space has to know what a property returns if it wants to use it, and once the user space knows that, the user space will also know the type and other details about the property, including knowing is it an array or not. Based on that, I'm against any kind of grouping or naming of the properties, was it based on the type of the property or is it an array or not, or supplying any details about the properties in any way to the user space. That would only complicate the life for the user space, as the grouping or naming, or supplying the details about the properties in any way, does not provide any information that the user space does not already have. The details about the properties would just be a sort of a useless noise for the user space that just has to be filtered out. Therefore I'm going to continue to propose that we expose the properties exactly the way I'm doing now: we'll have the "properties" directory that contains an attribute file for every property named with the names of the properties, and nothing else. The output formats we can still debate about, but Andy had already good proposals for that. I'm still not planning to include the property exposure at the first stage. Well add it after the initial support is in. Thanks, -- heikki