Received: by 2002:a05:6a10:16a7:0:0:0:0 with SMTP id gp39csp87034pxb; Tue, 17 Nov 2020 21:55:30 -0800 (PST) X-Google-Smtp-Source: ABdhPJxB85VEZZ0DBLE5KcSkk5DzVCUFcA7TgdIorkXEU1Y8vIULckPrMkgb2/sz1hBqbw9PrOrB X-Received: by 2002:a17:906:5a96:: with SMTP id l22mr22306476ejq.303.1605678930633; Tue, 17 Nov 2020 21:55:30 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1605678930; cv=none; d=google.com; s=arc-20160816; b=NXgqWFZWFUK+h92P+PhAgze5LXh/nT6l1RjPoOcIQsN4IT1dTqhxcS4Zowg4z/6Dak PrP6vzztouWz5o4OIgO8NayEyelKlALLKljZGvm9xKUAqpZgZDgLgRkMsz2HWUwegchH O6OnKRa2wvdtbGkjYW69cfHA5ZAhq21ihjW2xRb93AC8m0nj70RR6d2xpHz8bZ3OZAtf C8/FqXMA0lpVjQRN5R3VxQ6jlOvjdXpDuV+XfSnTABZGnOfshugeBDGrV0fxYZ0xWyhD d50LyTPxrE5qPqbL2MYs6ryt/jU4csMGX0+z5HluNCxsh6Ccn0Geq7cr7+r6dMxpzx3I CJfQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:user-agent:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date :ironport-sdr:ironport-sdr; bh=3bCrktyo4NQXBVD3gagwT0stYBOyQkBRGVLSwxlQQo8=; b=NHmEh8erSzsytWYynJXsURsUEEZ+jS0pQEkccsoa6t2FIx5wKQNiUhyhEm25GYVzQv fyTGaom/9Yv9blX9Y7WLPrtFqJ+gU+cwJYrF0Ae5KM8gK6ilMiPuY/sgX6I3c/EZ6FRM 4zXTgYHHIyhhHS39HvebhmNw7Qk5uWDQ3QHs2pS0zx0H/LTHB8/WFHsd67n26yotjGZI T0J/9/H1tBWyq79ZEa34QaryvFqREr0qRE1ia7G4tUBYA3f5I2AefTSBAWHH+O6qJP69 t+MJGg9j1EdOU0u/N7r5TLC8EMhCp9jW29re7qUz1ttw+0U4p6frIGRe0DPhfNwnvp1K hfew== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 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. [23.128.96.18]) by mx.google.com with ESMTP id dt4si17788963ejc.439.2020.11.17.21.55.07; Tue, 17 Nov 2020 21:55:30 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 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 S1726131AbgKRFvd (ORCPT + 99 others); Wed, 18 Nov 2020 00:51:33 -0500 Received: from mga06.intel.com ([134.134.136.31]:11645 "EHLO mga06.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725355AbgKRFvd (ORCPT ); Wed, 18 Nov 2020 00:51:33 -0500 IronPort-SDR: SWkXhgLaMutfjDVsGUfSKQ94kf6q3C/+BRBkeufyCRtFUC/y+RbjZ14L+CnKiNFuUsF/xjlM5U GbSGr8D72dVA== X-IronPort-AV: E=McAfee;i="6000,8403,9808"; a="232683318" X-IronPort-AV: E=Sophos;i="5.77,486,1596524400"; d="scan'208";a="232683318" X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by orsmga104.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 17 Nov 2020 21:51:32 -0800 IronPort-SDR: 3y4xws2q4Zsz/zxIrUBmg7A1tXFbX1MmQFZwlMG2MFILlsunXgeYRExF38w9eQJ2xthh01yfsK 8Nwt6MY4Fsgg== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.77,486,1596524400"; d="scan'208";a="430691834" Received: from yilunxu-optiplex-7050.sh.intel.com (HELO localhost) ([10.239.159.141]) by fmsmga001.fm.intel.com with ESMTP; 17 Nov 2020 21:51:29 -0800 Date: Wed, 18 Nov 2020 13:47:18 +0800 From: Xu Yilun To: Richard Gong Cc: Moritz Fischer , trix@redhat.com, linux-fpga@vger.kernel.org, linux-kernel@vger.kernel.org, dinguyen@kernel.org, sridhar.rajagopal@intel.com, Richard Gong , yilun.xu@intel.com Subject: Re: [PATCHv1 3/4] dt-bindings: fpga: add authenticate-fpga-config property Message-ID: <20201118054718.GB14665@yilunxu-OptiPlex-7050> References: <1605204403-6663-1-git-send-email-richard.gong@linux.intel.com> <1605204403-6663-4-git-send-email-richard.gong@linux.intel.com> <20201115192106.GB283592@epycbox.lan> <20201116024758.GA6810@yilunxu-OptiPlex-7050> <20201117022453.GA12837@yilunxu-OptiPlex-7050> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Nov 17, 2020 at 09:39:55AM -0600, Richard Gong wrote: > > > On 11/16/20 8:24 PM, Xu Yilun wrote: > >On Mon, Nov 16, 2020 at 08:14:52AM -0600, Richard Gong wrote: > >> > >>Hi Yilun, > >> > >>On 11/15/20 8:47 PM, Xu Yilun wrote: > >>>On Sun, Nov 15, 2020 at 11:21:06AM -0800, Moritz Fischer wrote: > >>>>Hi Richard, > >>>> > >>>>On Thu, Nov 12, 2020 at 12:06:42PM -0600, richard.gong@linux.intel.com wrote: > >>>>>From: Richard Gong > >>>>> > >>>>>Add authenticate-fpga-config property for FPGA bitstream authentication. > >>>>> > >>>>>Signed-off-by: Richard Gong > >>>>>--- > >>>>> Documentation/devicetree/bindings/fpga/fpga-region.txt | 1 + > >>>>> 1 file changed, 1 insertion(+) > >>>>> > >>>>>diff --git a/Documentation/devicetree/bindings/fpga/fpga-region.txt b/Documentation/devicetree/bindings/fpga/fpga-region.txt > >>>>>index e811cf8..7a512bc 100644 > >>>>>--- a/Documentation/devicetree/bindings/fpga/fpga-region.txt > >>>>>+++ b/Documentation/devicetree/bindings/fpga/fpga-region.txt > >>>>>@@ -187,6 +187,7 @@ Optional properties: > >>>>> - external-fpga-config : boolean, set if the FPGA has already been configured > >>>>> prior to OS boot up. > >>>>> - encrypted-fpga-config : boolean, set if the bitstream is encrypted > >>>>>+- authenticate-fpga-config : boolean, set if do bitstream authentication > >>>>It is unclear to me from the description whether this entails > >>>>authentication + reconfiguration or just authentication. > >>>> > >>>>If the latter is the case this should probably be described as such. > >>> > >>>If it is just authentication, do we still need to disable bridges in > >>>fpga_region_program_fpga? > >>> > >> > >>Yes. > >> > >>Except for the actual configuration of the device, the authentication > >>feature is the same as FPGA configuration. > > > >FPGA Bridges gate bus signals between a host and FPGA. So the FPGA > >region could not be accessed by host when doing configuration. But for > >this authentication, we are just writing the flash, we don't actually > >touch the FPGA soft logic. The host should still be able to operate on > >the old logic before reboot, is it? > > > Yes, it's feasible in theory but doesn't make much sense in practice. I > prefer to keep fpga_region_program_fpga() unchanged. I'm thinking of the case of inband reprograming, that the QSPI flash controller itself is embedded in FPGA soft logic, then maybe host still need to access FPGA on authentication. Thanks, Yilun > >> > >>>I'm wondering if the FPGA functionalities could still be working when > >>>the authenticating is ongoing, or when the authenticating is failed. > >>> > >> > >> > >> > >>>Thanks, > >>>Yilun > >>> > >>>> > >>>>> - region-unfreeze-timeout-us : The maximum time in microseconds to wait for > >>>>> bridges to successfully become enabled after the region has been > >>>>> programmed. > >>>>>-- > >>>>>2.7.4 > >>>>> > >>>> > >>>>Thanks