From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754036AbdCBCRn (ORCPT ); Wed, 1 Mar 2017 21:17:43 -0500 Received: from mga01.intel.com ([192.55.52.88]:62054 "EHLO mga01.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753448AbdCBCRk (ORCPT ); Wed, 1 Mar 2017 21:17:40 -0500 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.35,228,1484035200"; d="scan'208";a="231287174" 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/ACAAC3dgP//5QyA Date: Thu, 2 Mar 2017 02:17:36 +0000 Message-ID: <1488362309.4010.23.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> <1488358248.4010.17.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: <170ADE58F7E7A541B7B518D6A1629454@intel.com> 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 v222Hled011144 On Rab, 2017-03-01 at 12:34 +0100, Arnd Bergmann wrote: > On Wed, Mar 1, 2017 at 11:42 AM, Loh, Tien Hock com> wrote: > > > > On Rab, 2017-03-01 at 10:01 +0100, Arnd Bergmann wrote: > > > > > > On Wed, Mar 1, 2017 at 8:23 AM, Loh, Tien Hock > > el.c > > > 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. > Ah, I had not realized this is for fpga_manager. > > Why not put the attributes into /sys/class/fpga_manager/*/ then > along with the other attributes that exist there? That way, we have > an interface that works for all users of drivers/fpga/ > Well, this is not only for fpga_manager, but often time used to ensure that the correct hardware is programmed into the FPGA by checking the sysid after fpga_manager reconfigures the hardware. Systems without fpga_manager can still use sysid and timestamp to ensure the hardware is as expected value. What do you think of /sys/class/fpga_sysid/*/id and /sys/class/fpga_sysid/*/timestamp? > > > > 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. > Ok. > >      Arnd