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 D8D92C4167B for ; Thu, 2 Nov 2023 15:05:37 +0000 (UTC) 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=ZNGK3Xl7RmYeI2Jg87bkpT9Gn6rAxczo8BUF049MJzM=; b=RYlousZ5LrT4gQ Y7X1hgHXVNOLH41HFiEsRc4SJFQW+U+HtggU69dOjFOrof08ThKRUZSaF/wqMxEfrLaqlnCGVe0jX hY1CXORkw5cWqAzeKLgzwPLtcanglpHH63rxbBWPsGqb1emtttNAAF56V7JSPF0F/ZyLudo3d32vr ovGLfrZks2VvrePi5RmTggo6mPCQyvvX3gzpJ8/T9tb4vK33tmVsK1mIff2OGNdXn4mYyj9U3a5tq uMwaLy6JD31SZKyeFnIu12FtbJ/VXP1P1zqsA9ObL9ZOv4tIqqTfBfMIGfEveZKOCMopZlLOPbCAm Xh74aPIPkH2TxbDaqa2g==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.96 #2 (Red Hat Linux)) id 1qyZFo-009iGC-1t; Thu, 02 Nov 2023 15:05:04 +0000 Received: from foss.arm.com ([217.140.110.172]) by bombadil.infradead.org with esmtp (Exim 4.96 #2 (Red Hat Linux)) id 1qyZFl-009iEy-0p for linux-arm-kernel@lists.infradead.org; Thu, 02 Nov 2023 15:05:03 +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 428792F4; Thu, 2 Nov 2023 08:05:37 -0700 (PDT) Received: from pluto (unknown [172.31.20.19]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 4ABEF3F738; Thu, 2 Nov 2023 08:04:53 -0700 (PDT) Date: Thu, 2 Nov 2023 15:04:43 +0000 From: Cristian Marussi To: Oleksii Moisieiev Cc: "sudeep.holla@arm.com" , Rob Herring , Krzysztof Kozlowski , Conor Dooley , Linus Walleij , "linux-arm-kernel@lists.infradead.org" , "devicetree@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "linux-gpio@vger.kernel.org" Subject: Re: [RFC v5 2/5] drivers: firmware: scmi: Introduce scmi_get_max_msg_size function Message-ID: References: <9c9660c1-ab64-4186-917d-2007d88ce7c7@epam.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <9c9660c1-ab64-4186-917d-2007d88ce7c7@epam.com> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20231102_080501_346612_83320D50 X-CRM114-Status: GOOD ( 19.39 ) 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 Thu, Nov 02, 2023 at 01:57:24PM +0000, Oleksii Moisieiev wrote: > Hi Cristian, > Hi, > Just found an interesting note in the PINCTRL_CONFIG_SET command > description: > > The maximum value of this field is limited by > the transport used. The agent needs to specify > this field such that the entire command can be > accommodated within the transport chosen. > Yes I am aware of that. > Furthermore, I observed the absence of a skip_configs parameter. > > From my understanding, this implies that the maximum number of > configurations should not exceed the msg_max_size allowed by the > protocol, enabling the transmission of only one message to the SCMI > server at a time. > Yes that is correct, my understanding is that the transmitter is in charge of building a message whose payload can fit into the maximum message size allowed by the underlying configured transport. > Given this constraint, it seems we might not require additional helper > functions. We could potentially just verify against msg_max_size. > Indeed for that reason the scmi_get_max_msg_size that you introduced is just enough since it allows you to peek into the transport and get the max_msg_size...the misunderstanding is around the fact that I was simply meaning that you should plug it into some new helper_ops so that yo can call it like: max_msg = ph->hops->get_max_msg_size(ph); (like iterators or get_extended_name) Because in this way you could use it also when the protocol is build as a loadable module, thing that now it is possible only for vendor defined protocols, but we could also easily switch all the base protocols to be selectable via Kconfig and =m in the future (if ever) Your helper is fine by itself it is just that it cannot be called by a protocol defined to loaded as a module because the symbol is not exported and, indeed, we introduced the ph->hops thing just for this reason, i.e. to have a set of common protocol utilities that can be called even from loadable modules protocols without the need to export every single symbol. The reference to iterators and extended_name was misleading probably...my bad...or I am still missing something :D Thanks, Cristian _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel