Received: by 2002:a25:8b12:0:0:0:0:0 with SMTP id i18csp1617816ybl; Wed, 14 Aug 2019 21:16:48 -0700 (PDT) X-Google-Smtp-Source: APXvYqxW7LvgFajM0U0yHVAndOeUw5EZBzGZbCRStm9Hkyy47yyhJJB9mXSpdFvV5Y/U8lCxc5r6 X-Received: by 2002:a17:90a:22f0:: with SMTP id s103mr552549pjc.56.1565842608530; Wed, 14 Aug 2019 21:16:48 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1565842608; cv=none; d=google.com; s=arc-20160816; b=z0fZUgVaYR9jYUYLjKkUdv4yrjaKc8uzDAnN773tWqcj0tPEjWuuDr8ODQx4jBgYXl LjFWPo7/NTuBdJSAD85TUaBiUmbBC8bf5lCa/5X334TEcBCGS1SZcrA1jxsdFVAL33kB CvUAZJVRj3ACwodKilp34MVaYsWiNysU4URGwAUGbOxzlAuRPIKaAv2vIyqHtJ8C/Uub ++AQlKLZPiDd3+kYGR0pB7v64tFa03lFqqKl2/vY1rYMICjAyuNZ0pwedI0AM3KxA9AZ OyxVn1RCZEw/lnnPqNPb7hBpYjzDyZ/42Xxcp/slT7Y5P8umZuuFjzS3a83vAaFq25EA 28Gw== 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=Fi22FU9KFhHNkHfgALPlPPW0Ft09lRq+/Xar1nBMX60=; b=Y7xsAWfaTPqaLXndLo9AnCldnRWHH1zc5vGu7ngoUyMoXAr4ZHjeV0UlvdqC4AxO+J c0GAYV38DTsy0oJ4+lg2+TstXY3G8FUuz5T6V+GFbxTQnqcWYRK2W9BwOoQoWvDFwH/i U1Ilp1apee7K3/pf8McLcEIKFaWkIIw7si4S9DdV7FCoATiUIRDJNYI6nK89GJrWNSan tKa3RIpAPJR7a6lxcOeRE+vaXKLi4617rNsTn0BAw3Agzeu1kqeXXfQsI54S0dvLrD7b rD+AqKcSEACsx7b3toZBCRclXL9QjtBxoFLaxBdxxJAMwZCHogL7AD8TYRzLJcunkqyB C50w== 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 bo6si292197pjb.1.2019.08.14.21.16.32; Wed, 14 Aug 2019 21:16:48 -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 S1726435AbfHOEPV (ORCPT + 99 others); Thu, 15 Aug 2019 00:15:21 -0400 Received: from mga04.intel.com ([192.55.52.120]:58501 "EHLO mga04.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725875AbfHOEPU (ORCPT ); Thu, 15 Aug 2019 00:15:20 -0400 X-Amp-Result: UNKNOWN X-Amp-Original-Verdict: FILE UNKNOWN X-Amp-File-Uploaded: False Received: from fmsmga003.fm.intel.com ([10.253.24.29]) by fmsmga104.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 14 Aug 2019 21:15:20 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.64,387,1559545200"; d="scan'208";a="184514859" Received: from hao-dev.bj.intel.com (HELO localhost) ([10.238.157.65]) by FMSMGA003.fm.intel.com with ESMTP; 14 Aug 2019 21:15:18 -0700 Date: Thu, 15 Aug 2019 11:58:04 +0800 From: Wu Hao To: Scott Wood Cc: Greg KH , 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 01/12] fpga: dfl: fme: support 512bit data width PR Message-ID: <20190815035804.GA29090@hao-dev> References: <1563857495-26692-1-git-send-email-hao.wu@intel.com> <1563857495-26692-2-git-send-email-hao.wu@intel.com> <20190724093532.GB29532@kroah.com> <20190724142235.GE8463@hao-dev> <32c46e3de1a6641eb0d5940868f7d8b8a30181d3.camel@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <32c46e3de1a6641eb0d5940868f7d8b8a30181d3.camel@redhat.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, Aug 14, 2019 at 11:34:15AM -0500, Scott Wood wrote: > On Wed, 2019-07-24 at 22:22 +0800, Wu Hao wrote: > > On Wed, Jul 24, 2019 at 11:35:32AM +0200, Greg KH wrote: > > > On Tue, Jul 23, 2019 at 12:51:24PM +0800, Wu Hao wrote: > > > > > > > > @@ -67,8 +69,43 @@ > > > > #define PR_WAIT_TIMEOUT 8000000 > > > > #define PR_HOST_STATUS_IDLE 0 > > > > > > > > +#if defined(CONFIG_X86) && defined(CONFIG_AS_AVX512) > > > > + > > > > +#include > > > > +#include > > > > + > > > > +static inline int is_cpu_avx512_enabled(void) > > > > +{ > > > > + return cpu_feature_enabled(X86_FEATURE_AVX512F); > > > > +} > > > > > > That's a very arch specific function, why would a driver ever care about > > > this? > > > > Yes, this is only applied to a specific FPGA solution, which FPGA > > has been integrated with XEON. Hardware indicates this using register > > to software. As it's cpu integrated solution, so CPU always has this > > AVX512 capability. The only check we do, is make sure this is not > > manually disabled by kernel. > > > > With this hardware, software could use AVX512 to accelerate the FPGA > > partial reconfiguration as mentioned in the patch commit message. > > It brings performance benifits to people who uses it. This is only one > > optimization (512 vs 32bit data write to hw) for a specific hardware. > > I thought earlier you said that 512 bit accesses were required for this > particular integrated-only version of the device, and not just an > optimization? yes, some optimization implemented in a specific integrated-only version of hardware, this patch is used to support that particular hardware. This is also the reason you see code here to check hardware revision in this patch. > > > > > +#else > > > > +static inline int is_cpu_avx512_enabled(void) > > > > +{ > > > > + return 0; > > > > +} > > > > + > > > > +static inline void copy512(const void *src, void __iomem *dst) > > > > +{ > > > > + WARN_ON_ONCE(1); > > > > > > Are you trying to get reports from syzbot? :) > > > > Oh.. no.. I will remove it. :) > > > > Thank you very much! > > What's wrong with this? The driver should never call copy512() if > is_cpu_avx512_enabled() returns 0, and if syzbot can somehow make the driver > do so, then yes we do want a report. Yes, you are right, in previous version, it doesn't have avx512 enable check there, so it's possible to have false reporting, it should be fine after driver does early check on this during probe. As this patch has been dropped from main patchset, may rework it later and resubmit. Thanks for the comments. Hao > > -Scott >