From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-5.5 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 7C951C47082 for ; Mon, 7 Jun 2021 18:04:30 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 4281A61001 for ; Mon, 7 Jun 2021 18:04:30 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 4281A61001 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=arm.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=nRM/2fo2od+aWCKLuc4Q3+ZqrnG1JON5ckl13yRumcY=; b=Qaegmwoei1LuC1 KX8hbJ0NYnLnILrtmYgaBKUZ9Z87Ndo0mDFZ4zRv7SAdIB/fZSOej60BFePJy+FTPDbF3L1SWydug bOwJCxtzqOsjfhak/85OTOf/7ywiuMRMdhDIEkSk+mgSqIgmmb6mrGScUhCpVTF2aio2Yu3/Ay8/0 J8/xkFOJNr+DzWkKuCAsK1V1OzjMTJHSjlBeDOnYdRL0FRqJIKfF/In8yo8kSlqha/VXjunkM5AHk XwBcbJwrU5WeOJMCmBFVMJkXNqxOcPY7oV2KeqLCwKCTdlzPjhKKMVHyp7sdNR5ekFLtuQ+RXQT7V rU0KxOF2KjUQ+h03b8Bw==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1lqJZQ-004xON-QR; Mon, 07 Jun 2021 18:01:52 +0000 Received: from foss.arm.com ([217.140.110.172]) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1lqJZL-004xNw-QH for linux-arm-kernel@lists.infradead.org; Mon, 07 Jun 2021 18:01:50 +0000 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 6AA3812FC; Mon, 7 Jun 2021 11:01:46 -0700 (PDT) Received: from e120937-lin (unknown [172.31.20.19]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id AB31D3F73D; Mon, 7 Jun 2021 11:01:44 -0700 (PDT) Date: Mon, 7 Jun 2021 19:01:37 +0100 From: Cristian Marussi To: Sudeep Holla Cc: linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, james.quinlan@broadcom.com, Jonathan.Cameron@Huawei.com, f.fainelli@gmail.com, etienne.carriere@linaro.org, vincent.guittot@linaro.org, souvik.chakravarty@arm.com Subject: Re: [RFC PATCH 01/10] firmware: arm_scmi: Reset properly xfer SCMI status Message-ID: <20210607180137.GB40811@e120937-lin> References: <20210606221232.33768-1-cristian.marussi@arm.com> <20210606221232.33768-2-cristian.marussi@arm.com> <20210607173809.et6fzayvubsosvso@bogus> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20210607173809.et6fzayvubsosvso@bogus> User-Agent: Mutt/1.9.4 (2018-02-28) X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210607_110147_926735_77AAACCF X-CRM114-Status: GOOD ( 21.01 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Mon, Jun 07, 2021 at 06:38:09PM +0100, Sudeep Holla wrote: > On Sun, Jun 06, 2021 at 11:12:23PM +0100, Cristian Marussi wrote: > > When an SCMI command transfer fails due to some protocol issue an SCMI > > error code is reported inside the SCMI message payload itself and it is > > then retrieved and transcribed by the specific transport layer into the > > xfer.hdr.status field by transport specific .fetch_response(). > > > > The core SCMI transport layer never explicitly reset xfer.hdr.status, > > so when an xfer is reused, if a transport misbehaved in handling such > > status field, we risk to see an invalid ghost error code. > > > > Reset xfer.hdr.status to SCMI_SUCCESS right before each transfer is > > started. > > > > Any particular reason why it can't be part of xfer_get_init which has other > initialisations ? If none, please move it there. > Well it was there initially then I moved it here. The reason is mostly the same as the reason for the other patch in this series that adds a reinit_completion() in this same point: the core does not forbid to reuse an xfer multiple times, once obtained with xfer_get() or xfer_get_init(), and indeed some protocols do such a thing: they implements such do_xfer looping and bails out on error. In the way that it is implemented now in protocols poses no problem indeed because the do_xfer loop bails out on error and the xfer is put, but as soon as some protocol is implemented that violates this common practice and it just keeps on reuse an xfer after an error fo other do_xfers() this breaks...so it seemed more defensive to just reinit the completion and the status before each send. Thanks, Cristian > -- > Regards, > Sudeep _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel