Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752671AbdCALmW (ORCPT ); Wed, 1 Mar 2017 06:42:22 -0500 Received: from mail-oi0-f66.google.com ([209.85.218.66]:34102 "EHLO mail-oi0-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752369AbdCALmT (ORCPT ); Wed, 1 Mar 2017 06:42:19 -0500 MIME-Version: 1.0 In-Reply-To: <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> <1488358248.4010.17.camel@intel.com> From: Arnd Bergmann Date: Wed, 1 Mar 2017 12:34:57 +0100 X-Google-Sender-Auth: IjWibTKuc9LxR8kgvrvISsJ2Zms Message-ID: Subject: Re: [PATCH 1/1] drivers/misc: Add Intel System ID driver To: "Loh, Tien Hock" Cc: "linux-kernel@vger.kernel.org" , "Nguyen, Dinh" , "thloh85@gmail.com" , "gregkh@linuxfoundation.org" , "Gerlach, Matthew" Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1688 Lines: 35 On Wed, Mar 1, 2017 at 11:42 AM, Loh, Tien Hock 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 > 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/ > 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