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 46ACAD1CDC7 for ; Tue, 22 Oct 2024 09:38:46 +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=D4oyOua1l6uNqbnFmEwZ+/PqnGEgn5JKNMnJGinjVuI=; b=n/ASu8/iXjKzYxJPX6vGZrPyzn 3sDVMBl075ZaOuxCOwk8qXoqAADkijIeJ3bYJ7qDKIxYBqN68tE2AvGIQpNQM1T6fTegnJsdpXXdj H1JaD2m7Gli+ho4gIvWFo3IeTgxk3oEUUb2Hr5LEXDnOKV9afHdlPCO7y70qEIi8xUNlk+SvD/BG/ 888+LjxHJ7vACix9k4NI23uDspWULoBplGmJCrDJ2k4SMyXkT1GmkfkhN2nh1eVDcE6R9cd55hGRy lVuhjjrSAHu8IdoSFm14aylJIYXaYlCVSvjLAs76hVbmi1oh/JltH2SX1A6CS5RXgjzVtMKP0gTTK s8RudVwg==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.98 #2 (Red Hat Linux)) id 1t3BLX-0000000ANVr-19zU; Tue, 22 Oct 2024 09:38:35 +0000 Received: from foss.arm.com ([217.140.110.172]) by bombadil.infradead.org with esmtp (Exim 4.98 #2 (Red Hat Linux)) id 1t3B2L-0000000AJvy-09u2 for linux-arm-kernel@lists.infradead.org; Tue, 22 Oct 2024 09:18:47 +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 75A39497; Tue, 22 Oct 2024 02:19:13 -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 B01223F73B; Tue, 22 Oct 2024 02:18:41 -0700 (PDT) Date: Tue, 22 Oct 2024 10:18:34 +0100 From: Cristian Marussi To: Florian Fainelli Cc: Cristian Marussi , linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, arm-scmi@vger.kernel.org, sudeep.holla@arm.com, james.quinlan@broadcom.com, vincent.guittot@linaro.org, etienne.carriere@st.com, peng.fan@oss.nxp.com, michal.simek@amd.com, quic_sibis@quicinc.com, quic_nkela@quicinc.com, dan.carpenter@linaro.org Subject: Re: [PATCH v2 1/5] firmware: arm_scmi: Account for SHMEM memory overhead Message-ID: References: <20241021170726.2564329-1-cristian.marussi@arm.com> <20241021170726.2564329-2-cristian.marussi@arm.com> <5d6d545d-b6bc-4b37-b324-a664e4685100@broadcom.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5d6d545d-b6bc-4b37-b324-a664e4685100@broadcom.com> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20241022_021845_177436_0D11D14C X-CRM114-Status: GOOD ( 24.46 ) 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 Mon, Oct 21, 2024 at 10:11:44AM -0700, Florian Fainelli wrote: > On 10/21/24 10:07, Cristian Marussi wrote: > > Transports using shared memory have to consider the overhead due to the > > layout area when determining the area effectively available for messages. > > Hi Florian, thanks for having a look. > > Till now, such definitions were ambiguos across the SCMI stack and the > > overhead layout area was not considered at all. > > > > Add proper checks in the shmem layer to validate the provided max_msg_size > > against the effectively available memory area, less the layout. > > > > Signed-off-by: Cristian Marussi > > --- > > Note that as a consequence of this fix the default max_msg_size is reduced > > to 104 bytes for shmem-based transports, in order to fit into the most > > common implementations where the whole shmem area is sized at 128, > > including the 24 bytes of standard layout area. > > > > This should have NO bad side effects, since the current maximum payload > > size of any messages across any protocol (including all the known vendor > > ones) is 76 bytes. > > This looks good to me, just a small nit/suggestion: > > [snip] > > > size = resource_size(res); > > + if (cinfo->max_msg_size + SCMI_SHMEM_LAYOUT_OVERHEAD > size) { > > + dev_err(dev, "misconfigured SCMI shared memory\n"); > > + return IOMEM_ERR_PTR(-ENOSPC); > > + } > > + > > addr = devm_ioremap(dev, res->start, size); > > if (!addr) { > > dev_err(dev, "failed to ioremap SCMI %s shared memory\n", desc); > > diff --git a/drivers/firmware/arm_scmi/transports/mailbox.c b/drivers/firmware/arm_scmi/transports/mailbox.c > > index e7efa3376aae..4e0396250ad0 100644 > > --- a/drivers/firmware/arm_scmi/transports/mailbox.c > > +++ b/drivers/firmware/arm_scmi/transports/mailbox.c > > @@ -16,6 +16,8 @@ > > #include "../common.h" > > +#define SCMI_MAILBOX_MAX_MSG_SIZE 104 > > This IMHO, could be named SCMI_SHMEM_MAX_PAYLOAD_SIZE and used across all 3 > transports that are loosely SHMEM-based? Yes indeed, just I was not so sure we want to stick to the same default across different transports that are based on SHMEM....even though they are in fact the same as of now, and anyway modifiable via DT if his series goes in...I'll see what Sudeep prefers in these regards. Thanks, Cristian