Received: by 2002:a6b:fb09:0:0:0:0:0 with SMTP id h9csp2724570iog; Mon, 27 Jun 2022 01:16:52 -0700 (PDT) X-Google-Smtp-Source: AGRyM1ubD+K+r/I/M62cHEWvsKuYUjMs7IY16VOZmrNlpebYythB8ccEcndoecnwO/hsZFuEbO/5 X-Received: by 2002:a17:903:260e:b0:16a:22dd:b7d1 with SMTP id jd14-20020a170903260e00b0016a22ddb7d1mr13216069plb.84.1656317811737; Mon, 27 Jun 2022 01:16:51 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1656317811; cv=none; d=google.com; s=arc-20160816; b=E6aXbEtoR0TdAcNGIkwisHqYvRRV7UQis1DAzhAzXiQLVzmX7najiShJk5y2KHTnHy ra4wTLN6n5frvOKUlQHvOEXUphOsl+SpaFocxzWPWfxX2QQ8UyppJ9pjWY6hJr+InWZV oeh7dOtnoGZjTEB6OjgoRSuc7crH+rSNY8Kjs8BMMTt/yc4APIutyxrRe5fovUs0ixna i6d+AZ05qG4+JNggnaUMEAV2AvBLPU4oyp6Vy95OFP6ZlZE7QmD4MkympyifsVPcBGNa zdamWJCt5JDFwlSx8Si3/YpYMqL5Be3G7vNCgx8MfyNQ+NnYOqmUcHWDqUq0v7HpER2+ 0q5g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from :dkim-signature; bh=grWNLw22k/lLKjnhOUiaoH1YY3V5X2kwod7XqJbsp68=; b=e/WExwxEzWaCIe4wj/JH6YQCaK8/v4NgqfbEazTpI1rE7Z6VdmdXvuaPhWuwAIThnN v0xGUKtmjWldFMV7A+hIJzj11pv7PvVQ7iTReXarayMeE4PFB37qjRhmxGRAcy8jUe2W +x9ygTd/8/EFc6P5iY2PjtQazXGA4az3Y486DbcPqDggWCd5kQjiYdSMPV9KyuBUHs6V R2PM9l63b3n1wW8avZmVQaJ6npT3JWttyDsVHhDZpNxWsM7+yE7IP4CbWSodBDJU8364 z+6xOOo/+NMMtvU9u53NSlOMaDMrpFOCptorL8wcTL7/BT14RwMF3ArclvrLhSH3p6wZ 026Q== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=egN2nWFw; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id pg10-20020a17090b1e0a00b001e891954abdsi10265077pjb.122.2022.06.27.01.16.40; Mon, 27 Jun 2022 01:16:51 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=egN2nWFw; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233118AbiF0HqK (ORCPT + 99 others); Mon, 27 Jun 2022 03:46:10 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:52880 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229979AbiF0HqH (ORCPT ); Mon, 27 Jun 2022 03:46:07 -0400 Received: from mga04.intel.com (mga04.intel.com [192.55.52.120]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id ABDAA60E8; Mon, 27 Jun 2022 00:46:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1656315966; x=1687851966; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=6ur+/pIlVDwcPx+vLoZ2vqwsNPyXivHFAV4ACXjab44=; b=egN2nWFwNZWqR0fAEXFzvB0t/XEuFgva4VdR3EDiLyKURTqy/9CHRTfZ c2ii6whC6asgttmMP/I7kdXQn4K555bTlpQMtMXA3zwWhTDIR3A4wdpng e6XqypHAkiAjoBwcNx3FyvOzu5WrJ0TgentaTUmYSdP9cMMJtv307F9Tb G+5S4X0wvs5EGc+4FY3YbnUY7hEGbxIOZTr9/jeRCU7QWKEKF4zJS3/sJ f/fN76q1C9mNJv1RJj8YT0AJWksOpf5doiEHBy+v1wVPsuUoJIUYmwwpM SOHm19e9s4pnPrh2ZgFnxxZr+28yVez1VIh7XgxSEpSXrkXQHwbN1oUrk A==; X-IronPort-AV: E=McAfee;i="6400,9594,10390"; a="280148114" X-IronPort-AV: E=Sophos;i="5.92,225,1650956400"; d="scan'208";a="280148114" Received: from fmsmga006.fm.intel.com ([10.253.24.20]) by fmsmga104.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 27 Jun 2022 00:46:06 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.92,225,1650956400"; d="scan'208";a="836088244" Received: from unknown (HELO localhost.localdomain) ([10.226.216.90]) by fmsmga006.fm.intel.com with ESMTP; 27 Jun 2022 00:46:04 -0700 From: tien.sung.ang@intel.com To: yilun.xu@intel.com Cc: christophe.jaillet@wanadoo.fr, hao.wu@intel.com, linux-fpga@vger.kernel.org, linux-kernel@vger.kernel.org, mdf@kernel.org, tien.sung.ang@intel.com, trix@redhat.com Subject: Re: [PATCH v2] fpga: altera-cvp: Truncated bitstream error support Date: Mon, 27 Jun 2022 15:45:53 +0800 Message-Id: <20220627074553.3136597-1-tien.sung.ang@intel.com> X-Mailer: git-send-email 2.25.1 In-Reply-To: <20220608103058.GG481269@yilunxu-OptiPlex-7050> References: <20220608103058.GG481269@yilunxu-OptiPlex-7050> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-4.8 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_MED, SPF_HELO_NONE,SPF_NONE,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org > > Though without doubt, your solution is doable, I have a > > discussion with the Intel architect and they insisted that > > the device driver must not make such a decision. The decision to > > drop or accept a transfer is up to the firmware. The firmware > Why dropping or accepting is forbidden, but padding is allowed? If the > decision is no operation to the data, then padding should also be > forbidden. > > insisted that the buffer be padded with whatever value. They > If I understand right, the 2 decisions are conflicted. On one hand, > the driver should not care about the data. On another hand, the > driver should still care about the data for some rule. > So please firstly reach your agreement before making patches. Had some delays in replying,from the perspective of the driver, Intel architects want it to be just purely on the transfer of data without inspecting the data. If the size of a transfer is 4096bytes, we can padd it. I can do that which I think it is not an issue. Let me create a reworked patch to pad the payload with Zeros. Would this be OK for patch v3? > > Yes, it could look confusing to other programmers. And, yes, the > > padding doesn't matter. Let me relook into this. As the driver is > > already re-tested by the silicon validatioin. > > I want to avoid making any change as it > > would meant another couple of weeks of re-testing. > > Can this be accepted as it is? > Sorry, I can't. Some clarification is needed. Reply as above, let us implement the padding in the next patch v3. Appreciate your inputs. Thanks