Received: by 2002:a25:ad19:0:0:0:0:0 with SMTP id y25csp9744183ybi; Wed, 24 Jul 2019 09:12:25 -0700 (PDT) X-Google-Smtp-Source: APXvYqya3V4fGNMOHQD+j/84tHoeDFQ7r7Y/EGxpT11YDGDtmw2vbAB8N9NNKN/i+i8HpAxAMOPK X-Received: by 2002:a17:902:2862:: with SMTP id e89mr87033856plb.258.1563984745321; Wed, 24 Jul 2019 09:12:25 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1563984745; cv=none; d=google.com; s=arc-20160816; b=Ks0TEE0uz7iEdNxAldT9aB0IwE6OiHYWod+0wfO+lvYEL1geege8arnPbdq2Lcm/Jc os7rSgwWVJinCogwSOUySTrFSFN+f1fgZkOXIPkFNMZCSm4i5pa14luatU+J+Wd7lUln dKRohGjpkKB+RpXi2O+nlKTvmU8yDzIRMXOZ1tS2FspsG8OV9BQIehcwLrRgMQFt2NH3 OcD9qRLWttd2F4fGJfQUGRQT3loadV/xOgqsbw1IEy2EOf2MVwu/I2/1v7KTOlbTNgW+ IITx9GxsO4Aot04dCuL/H4HWySYnFOsGd3Z5D8O+T1L4bBFw7QT71hIzrBV24+HQxbYf OijA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=Uh8Wxj+dOPUlLmPnR6YUgCwOzLnfUnwBlbqGO9Qukjk=; b=vYIDaUeIkqLsSMalYN+MMQz4rUhG0yA8y4z8wTGjVIDjiJXkqTdmNceC2SUwOtLtie dGPGroa0mfW5tme8n+5cBSNFV/ByDphVeeJ/3l4sPTow0ywI+R0oov4i+tEaYAOABTyN EtlJ+2vaDxQ7+Bu6/qYmEfpubwcSRCvvR75bHFdFZ6G78mJgPnb85pK85E03H+4j1x4m hrX/Lhc2cxJM1EkwwFO16ymaRHwtXGKTHYp0MPPVK9DE1Fnr5R+hO+GwVnugYKHipV/L 2MpqGJ0w9WBt/OcqTqC6QmucryuIwrtb+LgdR2FEua2cNNElEK7TTNQfkCIofGdX8eJ2 q8yg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id 2si15639351pla.22.2019.07.24.09.12.10; Wed, 24 Jul 2019 09:12:25 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727193AbfGXNqU (ORCPT + 99 others); Wed, 24 Jul 2019 09:46:20 -0400 Received: from mga14.intel.com ([192.55.52.115]:17524 "EHLO mga14.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726769AbfGXNqU (ORCPT ); Wed, 24 Jul 2019 09:46:20 -0400 X-Amp-Result: UNKNOWN X-Amp-Original-Verdict: FILE UNKNOWN X-Amp-File-Uploaded: False Received: from fmsmga006.fm.intel.com ([10.253.24.20]) by fmsmga103.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 24 Jul 2019 06:46:19 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.64,303,1559545200"; d="scan'208";a="369299427" Received: from hao-dev.bj.intel.com (HELO localhost) ([10.238.157.65]) by fmsmga006.fm.intel.com with ESMTP; 24 Jul 2019 06:46:17 -0700 Date: Wed, 24 Jul 2019 21:29:20 +0800 From: Wu Hao To: Greg KH Cc: mdf@kernel.org, linux-fpga@vger.kernel.org, linux-kernel@vger.kernel.org, linux-api@vger.kernel.org, linux-doc@vger.kernel.org, atull@kernel.org, Ananda Ravuri , Xu Yilun Subject: Re: [PATCH v3 04/12] fpga: dfl: afu: add AFU state related sysfs interfaces Message-ID: <20190724132920.GB8463@hao-dev> References: <1563857495-26692-1-git-send-email-hao.wu@intel.com> <1563857495-26692-5-git-send-email-hao.wu@intel.com> <20190724094110.GD29532@kroah.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190724094110.GD29532@kroah.com> User-Agent: Mutt/1.5.24 (2015-08-30) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Jul 24, 2019 at 11:41:10AM +0200, Greg KH wrote: > On Tue, Jul 23, 2019 at 12:51:27PM +0800, Wu Hao wrote: > > This patch introduces more sysfs interfaces for Accelerated > > Function Unit (AFU). These interfaces allow users to read > > current AFU Power State (APx), read / clear AFU Power (APx) > > events which are sticky to identify transient APx state, > > and manage AFU's LTR (latency tolerance reporting). > > > > Signed-off-by: Ananda Ravuri > > Signed-off-by: Xu Yilun > > Signed-off-by: Wu Hao > > Acked-by: Alan Tull > > Signed-off-by: Moritz Fischer > > --- > > v2: rebased, and remove DRV/MODULE_VERSION modifications > > v3: update kernel version and date in sysfs doc > > --- > > Documentation/ABI/testing/sysfs-platform-dfl-port | 30 +++++ > > drivers/fpga/dfl-afu-main.c | 137 ++++++++++++++++++++++ > > drivers/fpga/dfl.h | 11 ++ > > 3 files changed, 178 insertions(+) > > > > diff --git a/Documentation/ABI/testing/sysfs-platform-dfl-port b/Documentation/ABI/testing/sysfs-platform-dfl-port > > index 6a92dda..5961fb2 100644 > > --- a/Documentation/ABI/testing/sysfs-platform-dfl-port > > +++ b/Documentation/ABI/testing/sysfs-platform-dfl-port > > @@ -14,3 +14,33 @@ Description: Read-only. User can program different PR bitstreams to FPGA > > Accelerator Function Unit (AFU) for different functions. It > > returns uuid which could be used to identify which PR bitstream > > is programmed in this AFU. > > + > > +What: /sys/bus/platform/devices/dfl-port.0/power_state > > +Date: July 2019 > > +KernelVersion: 5.4 > > +Contact: Wu Hao > > +Description: Read-only. It reports the APx (AFU Power) state, different APx > > + means different throttling level. When reading this file, it > > + returns "0" - Normal / "1" - AP1 / "2" - AP2 / "6" - AP6. > > + > > +What: /sys/bus/platform/devices/dfl-port.0/ap1_event > > +Date: July 2019 > > +KernelVersion: 5.4 > > +Contact: Wu Hao > > +Description: Read-write. Read or set 1 to clear AP1 (AFU Power State 1) > > + event. It's used to indicate transient AP1 state. > > So reading the value changes the state of the system? That's almost > always never a good idea. > > Force userspace to write the value to change something. Otherwise all > libraries that use sysfs will be accidentally changing the state of your > system without you ever knowing it. Oh.. I think the description makes some misunderstanding here, will fix it in the next version. This AP1/AP2 event will only be cleared by write 1 to it, read will not change the state. > > > + > > +What: /sys/bus/platform/devices/dfl-port.0/ap2_event > > +Date: July 2019 > > +KernelVersion: 5.4 > > +Contact: Wu Hao > > +Description: Read-write. Read or set 1 to clear AP2 (AFU Power State 2) > > + event. It's used to indicate transient AP2 state. > > + > > +What: /sys/bus/platform/devices/dfl-port.0/ltr > > +Date: July 2019 > > +KernelVersion: 5.4 > > +Contact: Wu Hao > > +Description: Read-write. Read and set AFU latency tolerance reporting value. > > + Set ltr to 1 if the AFU can tolerate latency >= 40us or set it > > + to 0 if it is latency sensitive. > > diff --git a/drivers/fpga/dfl-afu-main.c b/drivers/fpga/dfl-afu-main.c > > index 68b4d08..cb3f73e 100644 > > --- a/drivers/fpga/dfl-afu-main.c > > +++ b/drivers/fpga/dfl-afu-main.c > > @@ -141,8 +141,145 @@ static int port_get_id(struct platform_device *pdev) > > } > > static DEVICE_ATTR_RO(id); > > > > +static ssize_t > > +ltr_show(struct device *dev, struct device_attribute *attr, char *buf) > > +{ > > + struct dfl_feature_platform_data *pdata = dev_get_platdata(dev); > > + void __iomem *base; > > + u64 v; > > + > > + base = dfl_get_feature_ioaddr_by_id(dev, PORT_FEATURE_ID_HEADER); > > + > > + mutex_lock(&pdata->lock); > > + v = readq(base + PORT_HDR_CTRL); > > + mutex_unlock(&pdata->lock); > > Why do you need a lock to call readq()? What are you protecting here? If this code is running on 32bit machine, readq will be replaced with 2 readl operation. If that is the case, should we protect the code against it? > > > > + > > + return sprintf(buf, "%x\n", (u8)FIELD_GET(PORT_CTRL_LATENCY, v)); > > +} > > + > > +static ssize_t > > +ltr_store(struct device *dev, struct device_attribute *attr, > > + const char *buf, size_t count) > > +{ > > + struct dfl_feature_platform_data *pdata = dev_get_platdata(dev); > > + void __iomem *base; > > + u8 ltr; > > + u64 v; > > + > > + if (kstrtou8(buf, 0, <r) || ltr > 1) > > + return -EINVAL; > > Are you doing anything with this value? If not, how about just using > the sysfs boolean read function and if it is 1, then do the clearing? > > Same for all other show/store functions in here. Sure, will fix this in the next version. Thanks a lot for the comments. Hao > > thanks, > > greg k-h