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 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 smtp.lore.kernel.org (Postfix) with ESMTPS id EDB21CD5BB9 for ; Thu, 5 Sep 2024 12:45:14 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:List-Subscribe:List-Help :List-Post:List-Archive:List-Unsubscribe:List-Id:In-Reply-To:Content-Type: MIME-Version:References:Message-ID:Subject:Cc:To:From:Date:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=WNTusimQSygKNS7V9bllEPTc8gfBgD8sqTCIrU3YNNY=; b=Z6Yp801eATr06OKF6pGdVkj6PC CoMOhvwV0Y/LsdjTLv+KTuVVaBM/iF0bm8PaXeszC9Z9umYvLitRGfNOu+px138Yl4riYdFGAJsrI zb+3cdAIWpjOl9eALoSJ6TMbo0CAEZAy06r5MSZH6dI+0JeYs338tJSiUcH/gBW3QWa9KDhncvEDp NVSXLb3ZhzDfn9AZrq79rQZvOzIqA+MmU0zZzpebBJoVP+Fj6mDa7wPXWOxAIoxJiR/mNQo5iVxDz FVszjreAAhESwLY5XPZraWd6nvVKZwcwS2IQhLr0JlaKNtvvyjuE+KZC27kAq7FTGVmzAfmAXqyGp GsZPwLVg==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1smBrG-00000008O7P-3OFy; Thu, 05 Sep 2024 12:45:06 +0000 Received: from foss.arm.com ([217.140.110.172]) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1smBpu-00000008NQO-26wq for linux-arm-kernel@lists.infradead.org; Thu, 05 Sep 2024 12:43:43 +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 894D6FEC; Thu, 5 Sep 2024 05:44:08 -0700 (PDT) Received: from pluto (usa-sjc-mx-foss1.foss.arm.com [172.31.20.19]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 989353F73B; Thu, 5 Sep 2024 05:43:40 -0700 (PDT) Date: Thu, 5 Sep 2024 13:43:33 +0100 From: Cristian Marussi To: Sibi Sankar Cc: sudeep.holla@arm.com, cristian.marussi@arm.com, linux-kernel@vger.kernel.org, arm-scmi@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-arm-msm@vger.kernel.org, johan@kernel.org, konradybcio@kernel.org Subject: Re: [PATCH V2 2/2] firmware: arm_scmi: Skip adding bad duplicates Message-ID: References: <20240904031324.2901114-1-quic_sibis@quicinc.com> <20240904031324.2901114-3-quic_sibis@quicinc.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20240905_054342_640067_B1B74542 X-CRM114-Status: GOOD ( 25.99 ) 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: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Wed, Sep 04, 2024 at 04:46:08PM +0100, Cristian Marussi wrote: > On Wed, Sep 04, 2024 at 04:30:24PM +0100, Cristian Marussi wrote: > > On Wed, Sep 04, 2024 at 04:21:49PM +0100, Cristian Marussi wrote: > > > On Wed, Sep 04, 2024 at 08:43:24AM +0530, Sibi Sankar wrote: > > > > Ensure that the bad duplicates reported by the platform firmware doesn't > > > > get added to the opp-tables. > > > > > > > > > > Hi Sibi, > > > > > > so if the idea is to make the code more robust when FW sends BAD > > > duplicates, you necessarily need to properly drop opps in opp_count too. > > > > > > One other option would be to just loop with xa_for_each BUT opp_count is > > > used in a number of places...so first of all let's try drop count properly. > > > > > > Can you try this patch down below, instead of your patch. > > > If it solves, I will send a patch (after testing it a bit more :D) > > > > Hold on... I sent you a diff that does not apply probably on your tree due > > to some uncomitted local work of mine...my bad...let me resend. > > > > This one should be good...apologies > As a side comment about this, even though we certain can and should make the Kernel more robust to skip possible bad replies from FW (like with this or similar patches), if the bad replies comes by design since, as I have grasped from the other thread, the FW just ALSO exposes resources/OPPs that are just NOT usable by the Kernel OSPM/agent (but maybe by other agents), you should fix your FW to fully avoid the warnings...since the warnings in SCMI/perf are there exactly to catch this kind of situations... (even though we can deal better with the replies as with this patch) IOW, the SCMI server should expose to its agents only the subset of resources and characteristics that are supposed to be used by those respective agents (server can expose a per-agent view of the system)... ...because, even if innocuous and even though most of the time we can cope with such "alien" resources (with the FW simply replying with a DENY to any request not meant to be touched or the Kernel spotting such anomalies and ignoring them) all of these "alien" resources will generate some sort of uneeded background SCMI traffic (of DENY replies) Thanks, Cristian