Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752479AbdCAKm4 (ORCPT ); Wed, 1 Mar 2017 05:42:56 -0500 Received: from mga02.intel.com ([134.134.136.20]:18613 "EHLO mga02.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752250AbdCAKmi (ORCPT ); Wed, 1 Mar 2017 05:42:38 -0500 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.35,225,1484035200"; d="scan'208";a="230988589" From: "Loh, Tien Hock" To: "arnd@arndb.de" CC: "linux-kernel@vger.kernel.org" , "Nguyen, Dinh" , "thloh85@gmail.com" , "gregkh@linuxfoundation.org" , "Gerlach, Matthew" Subject: Re: [PATCH 1/1] drivers/misc: Add Intel System ID driver Thread-Topic: [PATCH 1/1] drivers/misc: Add Intel System ID driver Thread-Index: AQHSh3xEV1UiWY2US02NwdEQuVXhNaFpybMAgAArIICAC6nLgIAAI4+AgAACs4CACV+bAIAAG0wA///8/AA= Date: Wed, 1 Mar 2017 10:42:34 +0000 Message-ID: <1488358248.4010.17.camel@intel.com> References: <1487156981-4550-1-git-send-email-user@thloh-VirtualBox> <20170215171732.GA4548@kroah.com> <1487829507.2961.5.camel@intel.com> <1487837723.2961.7.camel@intel.com> <1488353034.3544.3.camel@intel.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.226.241.207] Content-Type: text/plain; charset="utf-8" Content-ID: MIME-Version: 1.0 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by mail.home.local id v21AkatE009590 Content-Length: 2134 Lines: 55 On Rab, 2017-03-01 at 10:01 +0100, Arnd Bergmann wrote: > On Wed, Mar 1, 2017 at 8:23 AM, Loh, Tien Hock om> wrote: > > > > Arnd, Greg, > Please don't top-post. OK. > > > > > I checked the attributes returned by the soc attribute subsystem, > > but > > it seems that it is lacking something equivalent to timestamp in > > the > > Intel System ID controller. Do you think it is better to add a new > > attribute (named timestamp) to soc or create a new sysfs entry like > > what I did? > It depends on how common and how important this attribute is. > > - if it's not overly important, just drop it entirely. > - if it's important enough that other SoCs are likely to have the > same >   kind of information, make it a standard attribute > - if this SoC is most likely the only one that will ever need it, but > it has >   important uses, I'd make it a custom attribute > > Another option would be to fold the timestamp into the revision > attribute, > but whether that is a reasonable place for it would in turn depend on > what the timestamp signifies. > > Can you explain what the timestamp is used for? Does it identify the > time that the hardware revision was made, the time that a software > was built which was loaded into it, or something else? > What kind of user space application would need this information? I just checked, and it seems like we can't put this into soc subsystem. In FPGA, we now can do partial reconfiguration, which "reconfigures" the hardware to have an updated sysid and timestamp value, and the base address of the Intel System ID may also be changed. This would require the driver to be a module that will be removed, probed again. The soc subsystem doesn't seem to be a suitable place to add this driver. A note on the timestamp, in the old days this is used to check that the BSP is using the correct FPGA hardware. I believe in Linux we should do the same in the driver, and if it not, the driver should print a warning. The timestamp's print is not exactly needed. I'll add the feature into the driver in the next patch. > >      Arnd Thanks Tien Hock