Received: by 2002:a05:6358:9144:b0:117:f937:c515 with SMTP id r4csp6657649rwr; Tue, 2 May 2023 03:47:28 -0700 (PDT) X-Google-Smtp-Source: ACHHUZ7ikcdIqFmaJQZD60nIrGp1T77lr4N+CTL1OakQy1PDSciOfFE+nI3GD96loeHqRERuBe/2 X-Received: by 2002:a17:90b:343:b0:23d:870:5244 with SMTP id fh3-20020a17090b034300b0023d08705244mr20813826pjb.13.1683024448004; Tue, 02 May 2023 03:47:28 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1683024447; cv=none; d=google.com; s=arc-20160816; b=J131OemV2B9Yz7gModpClaj5C/u+t8cDkCCtt28mJIcgrWqfUuPLVO4RADExTFhMwR UWWCVu5DtZGCJhwGVg/Ip27xH1kmkMEE5DtJ7XFmAuyniTV/IGHwss8JlaWyj0oerhyP ZSfTSgk1d58lpz1kk8Fw1oTVbeV24hz36mnFbWZb7I+EkabEBkNZvWBcEZ4cTWamsYGF /BdSXU6q6myt8DD8nt4SEovDiZfIRpQ4PmQaCcqctCemgXWFye/H4EM0OT3KwlH+kSOi 65EYYENqCodFcEQuHrAU8LRtS1a+ulPOMRlQE3Ue5obli161AlNgkz2HXGIh5aYOSj/6 +L3w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date; bh=tEWXvElLRaccUBrNLAbjvh3+JATukV9X4xPCxwbm0Ko=; b=bUDmKNJKpGWmkRliy2P9tfrucFbEQQRpxJ/cgn2MQD66vtS+JNlmDlCxyHV2imccZk XLMMGh/mT0nZgzaO2eriRZyx+aB//eyD0tSMvIkJyn4xfo7I+MCKM+QvKUeEG8A6JGZi QQITJzcto9lojH5iJwl/DR0OCun9RxHw2l2wqjewXM31ydSvBMKT7NypMjjVPBA1h3IC /SqxzuyG8VKdYK8AUr+yx2j7b0X/+pSmRctCQdkbPAnXfhKgney65RqrExUFHZQUoQ73 SY2Kpi9MTuAhVNc0r6kZVqXQy2kVkDr6xIktMY24IqXwGICxnlPL7YFsE/M3BRv90BAV nfMA== ARC-Authentication-Results: i=1; mx.google.com; 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=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id h11-20020a170902f54b00b001a6d4eab490si32207317plf.63.2023.05.02.03.47.15; Tue, 02 May 2023 03:47:27 -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; 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=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233644AbjEBKqr (ORCPT + 99 others); Tue, 2 May 2023 06:46:47 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:47042 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229936AbjEBKqp (ORCPT ); Tue, 2 May 2023 06:46:45 -0400 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id ABBAF193; Tue, 2 May 2023 03:46:42 -0700 (PDT) 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 59A18C14; Tue, 2 May 2023 03:47:26 -0700 (PDT) Received: from bogus (e103737-lin.cambridge.arm.com [10.1.197.49]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id E48603F64C; Tue, 2 May 2023 03:46:40 -0700 (PDT) Date: Tue, 2 May 2023 11:46:38 +0100 From: Sudeep Holla To: Nikunj Kela Cc: f.fainelli@gmail.com, cristian.marussi@arm.com, robh+dt@kernel.org, krzysztof.kozlowski+dt@linaro.org, Sudeep Holla , linux-arm-kernel@lists.infradead.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v4 2/2] firmware: arm_scmi: Augment SMC/HVC to allow optional parameters Message-ID: <20230502104638.kdncvotcuax2db3f@bogus> References: <20230409181918.29270-1-quic_nkela@quicinc.com> <20230418185659.29745-1-quic_nkela@quicinc.com> <20230418185659.29745-3-quic_nkela@quicinc.com> <6f806e8a-1f12-5793-66eb-d7497839ad14@quicinc.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6f806e8a-1f12-5793-66eb-d7497839ad14@quicinc.com> X-Spam-Status: No, score=-4.2 required=5.0 tests=BAYES_00,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 On Mon, May 01, 2023 at 07:39:29AM -0700, Nikunj Kela wrote: > Reminder: Please review this patch! Thanks > Since the current merge window is open, there is no rush and hence I had put this on hold until merge window close. Anyways, it looks good in general. Couple of minor nits below: > On 4/18/2023 11:56 AM, Nikunj Kela wrote: > > This patch add support for passing shmem channel address as parameters > > in smc/hvc call. The address is split into 4KB-page and offset. > > This patch is useful when multiple scmi instances are using same smc-id > > and firmware needs to distinguish among the instances. > > Drop the term "patch". You can refer it as change. It is not match after it is applied to the git. > > Signed-off-by: Nikunj Kela > > --- > > drivers/firmware/arm_scmi/driver.c | 1 + > > drivers/firmware/arm_scmi/smc.c | 14 +++++++++++++- > > 2 files changed, 14 insertions(+), 1 deletion(-) > > > > diff --git a/drivers/firmware/arm_scmi/driver.c b/drivers/firmware/arm_scmi/driver.c > > index e7d97b59963b..b5957cc12fee 100644 > > --- a/drivers/firmware/arm_scmi/driver.c > > +++ b/drivers/firmware/arm_scmi/driver.c > > @@ -2914,6 +2914,7 @@ static const struct of_device_id scmi_of_match[] = { > > #endif > > #ifdef CONFIG_ARM_SCMI_TRANSPORT_SMC > > { .compatible = "arm,scmi-smc", .data = &scmi_smc_desc}, > > + { .compatible = "arm,scmi-smc-param", .data = &scmi_smc_desc}, > > #endif > > #ifdef CONFIG_ARM_SCMI_TRANSPORT_VIRTIO > > { .compatible = "arm,scmi-virtio", .data = &scmi_virtio_desc}, > > diff --git a/drivers/firmware/arm_scmi/smc.c b/drivers/firmware/arm_scmi/smc.c > > index 93272e4bbd12..71e080b70df5 100644 > > --- a/drivers/firmware/arm_scmi/smc.c > > +++ b/drivers/firmware/arm_scmi/smc.c > > @@ -20,6 +20,11 @@ > > #include "common.h" > > +#define SHMEM_SHIFT 12 > > +#define SHMEM_SIZE (_AC(1, UL) << SHMEM_SHIFT) > > +#define SHMEM_PAGE(x) ((unsigned long)((x) >> SHMEM_SHIFT)) Since we are dealing with 4kB pages only, I prefer to do: #define SHMEM_SIZE (SZ_4K) #define SHMEM_SHIFT 12 #define SHMEM_PAGE(x) (_UL((x) >> SHMEM_SHIFT)) > > +#define SHMEM_OFFSET(x) ((x) & (SHMEM_SIZE - 1)) > > + Also it is definitely worth adding comment about supporting just 4kB pages and limitations associated with it here(e.g. we can support up to 44 bit address) and also parameters to the SMC call so that others get clear idea on how to use it if they need that in the future. > > /** > > * struct scmi_smc - Structure representing a SCMI smc transport > > * > > @@ -30,6 +35,7 @@ > > * @inflight: Atomic flag to protect access to Tx/Rx shared memory area. > > * Used when operating in atomic mode. > > * @func_id: smc/hvc call function id > > + * @param: physical address of the shmem channel > > */ > > struct scmi_smc { > > @@ -40,6 +46,7 @@ struct scmi_smc { > > #define INFLIGHT_NONE MSG_TOKEN_MAX > > atomic_t inflight; > > u32 func_id; > > + phys_addr_t param; > > }; > > static irqreturn_t smc_msg_done_isr(int irq, void *data) > > @@ -137,6 +144,8 @@ static int smc_chan_setup(struct scmi_chan_info *cinfo, struct device *dev, > > if (ret < 0) > > return ret; > > + if (of_device_is_compatible(dev->of_node, "arm,scmi-smc-param")) > > + scmi_info->param = res.start; > > /* > > * If there is an interrupt named "a2p", then the service and > > * completion of a message is signaled by an interrupt rather than by > > @@ -179,6 +188,8 @@ static int smc_send_message(struct scmi_chan_info *cinfo, > > { > > struct scmi_smc *scmi_info = cinfo->transport_info; > > struct arm_smccc_res res; > > + unsigned long page = SHMEM_PAGE(scmi_info->param); > > + unsigned long offset = SHMEM_OFFSET(scmi_info->param); While I see you initialise param in smc_chan_setup, I wonder why the page and offset itself be initialised once and reused instead of computing the same fixed value on every smc_send_message. You can probably have param_page and param_offset stashed instead of just single param value ? > > /* > > * Channel will be released only once response has been > > @@ -188,7 +199,8 @@ static int smc_send_message(struct scmi_chan_info *cinfo, > > shmem_tx_prepare(scmi_info->shmem, xfer, cinfo); > > - arm_smccc_1_1_invoke(scmi_info->func_id, 0, 0, 0, 0, 0, 0, 0, &res); > > + arm_smccc_1_1_invoke(scmi_info->func_id, page, offset, 0, 0, 0, 0, 0, > > + &res); > > /* Only SMCCC_RET_NOT_SUPPORTED is valid error code */ > > if (res.a0) { -- Regards, Sudeep