Received: by 2002:a05:6a10:f3d0:0:0:0:0 with SMTP id a16csp3285229pxv; Mon, 28 Jun 2021 00:45:17 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwBxtHwHXFyLwQZP6QrHp4AHpcCKNnnLkQAUMXaCK7fRh3IoXtjuefklT6zXfLDx5PDTHhP X-Received: by 2002:a05:6402:3588:: with SMTP id y8mr8791806edc.383.1624866317725; Mon, 28 Jun 2021 00:45:17 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1624866317; cv=none; d=google.com; s=arc-20160816; b=JxqprgPZwtYCM+lEZCwIAiohiwyRTc1HZVhPz7VEgf6C1xjea7JrGQz0OGSRLraQ8U sZhKe4jegd32Q2x8JwVQv/NIyeWBwAKbyEh3HSJ1/CfDrag7pTG8oXhqF/qAoUquFOpx Z/teGS9vJ+YKda3DQV9NvAvtts7LXeGRISFE/MFfo2FLl7HgiMCOeoVPPLA/9JR105BY Af03UNEESQKjcwSSn18/cgcVb39zzgleLgHsQeGw5SYm2u8d113Mceiu32igBum9AvxG o15fJIiyI6lb7zK6NfQkfNHb3bJ/PAxnft7/I+235DmZRS9s2Z1zXENQy6kUlkuRc5gy s7WA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date; bh=BRa7pupeCdyK+Dg1Z3qVYWZsLrR91kr256G5L/zwqqA=; b=i4+3K0cgJ7aE9p/1TMiHNHDIvHHrJOfjBgaFCheTNLbtSS8TppNSvEp7O3yCs24kB0 rRTHUsUu4vPHDeiybfWY4jGGFTLa0h9VBcZadPBz608+id4wuCu4VO0qPqC5vh+5RuTn XOhwjDYpItHrn3k4Jx8zTjnBPXuDnv27mr1fnb+SeI9hOB+03EDWprv47vlliYhXTmRy jB6IZYyBhrHUV08RhZSlPUSHeB8i2VJih2mStrymVlsq420QWjqdp4KSRMTfogrwZW5B Yn+/OZ2vmBhTRohLLbIPrMMvtNbmxsT1POnkUD1RoFlLX7lO7sp9cRb0+1JsayDyp8un qLTQ== 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 di18si12758906edb.218.2021.06.28.00.44.52; Mon, 28 Jun 2021 00:45:17 -0700 (PDT) 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 S231506AbhF1HLD (ORCPT + 99 others); Mon, 28 Jun 2021 03:11:03 -0400 Received: from mga14.intel.com ([192.55.52.115]:48616 "EHLO mga14.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230134AbhF1HLC (ORCPT ); Mon, 28 Jun 2021 03:11:02 -0400 X-IronPort-AV: E=McAfee;i="6200,9189,10028"; a="207717468" X-IronPort-AV: E=Sophos;i="5.83,305,1616482800"; d="scan'208";a="207717468" Received: from orsmga004.jf.intel.com ([10.7.209.38]) by fmsmga103.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 28 Jun 2021 00:08:36 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.83,305,1616482800"; d="scan'208";a="557466718" Received: from yilunxu-optiplex-7050.sh.intel.com (HELO localhost) ([10.239.159.162]) by orsmga004.jf.intel.com with ESMTP; 28 Jun 2021 00:08:33 -0700 Date: Mon, 28 Jun 2021 15:03:15 +0800 From: Xu Yilun To: trix@redhat.com Cc: mdf@kernel.org, hao.wu@intel.com, michal.simek@xilinx.com, linux-fpga@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org Subject: Re: [PATCH v5 4/4] fpga: use reimage ops in fpga_mgr_load() Message-ID: <20210628070315.GF72330@yilunxu-OptiPlex-7050> References: <20210625195849.837976-1-trix@redhat.com> <20210625195849.837976-6-trix@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20210625195849.837976-6-trix@redhat.com> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Jun 25, 2021 at 12:58:49PM -0700, trix@redhat.com wrote: > From: Tom Rix > > If the fpga_image_info flags FPGA_MGR_REIMAGE bit is set > swap out the reconfig ops for the reimage ops and do > the load. > > Signed-off-by: Tom Rix > --- > drivers/fpga/fpga-mgr.c | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/drivers/fpga/fpga-mgr.c b/drivers/fpga/fpga-mgr.c > index c8a6bfa037933..5e53a0508087a 100644 > --- a/drivers/fpga/fpga-mgr.c > +++ b/drivers/fpga/fpga-mgr.c > @@ -419,6 +419,9 @@ int fpga_mgr_load(struct fpga_manager *mgr, struct fpga_image_info *info) > { > const struct fpga_manager_update_ops *uops = &mgr->mops->reconfig; > > + if (info->flags & FPGA_MGR_REIMAGE) > + uops = &mgr->mops->reimage; > + So seems there is no big difference on processing 'reconfig' & 'reimage' in FPGA mgr framework. We may not have to introduce 2 sets of ops in fpga_mgr. Could we just reuse the fpga_mgr_ops for reimage? The fpga_mgr_ops.write_init() will pass the fpga_image_info to device driver, and driver could be aware of the REIMAGE flag. Just like the handling of other flags in fpga_image_info. Thanks, Yilun > if (info->sgt) > return fpga_mgr_buf_load_sg(mgr, info, info->sgt, uops); > if (info->buf && info->count) > -- > 2.26.3