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 F0E7DC3271E for ; Mon, 8 Jul 2024 18:00:22 +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:Content-Transfer-Encoding: Content-Type:In-Reply-To:From:References:CC:To:Subject:MIME-Version:Date: Message-ID:Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=IaJb+PETvq7g3aOwj2sxGHfs7FuI3lps1sYrTFMHv70=; b=yeuN4uB7APfAURQXhW8nvov7iq c/mVsxu71TOdeU518m0/gx/zVn1pdZUBZR0bwEXNaKQ9xSPqUPIGJS3pmcIOJPM2dk5s2dipniD/u gmiUPQIdpTMVM+x0m6E2rFM0LPN9WHF1pDo/lhPDZH55bQnEqvW/m17bS8EnRzxh/e7b+jU4FElPk mSa0ntaL+UJr0KxUar76fJr43JMqzv7S8a0ciei0nhKJNOxSSFMWJquSq6plXBQabSvMhYyv0Y3NJ yxZSEy9IsfVzCrS1sAC+s538nYtJ8+Dh5mpYt3XJiEMEsdc/zQtg96l3jnikwmY99X6+8sbjYiEbX RSvctYqg==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1sQsem-00000004eY4-2V7r; Mon, 08 Jul 2024 18:00:08 +0000 Received: from mx0a-0031df01.pphosted.com ([205.220.168.131]) by bombadil.infradead.org with esmtps (Exim 4.97.1 #2 (Red Hat Linux)) id 1sQseU-00000004eWu-0wSC for linux-arm-kernel@lists.infradead.org; Mon, 08 Jul 2024 17:59:54 +0000 Received: from pps.filterd (m0279862.ppops.net [127.0.0.1]) by mx0a-0031df01.pphosted.com (8.18.1.2/8.18.1.2) with ESMTP id 468C73pQ024563; Mon, 8 Jul 2024 17:59:35 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=quicinc.com; h= cc:content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to; s=qcppdkim1; bh= IaJb+PETvq7g3aOwj2sxGHfs7FuI3lps1sYrTFMHv70=; b=FWyjEsFDlBEym5bF /dCN5J7fMB4+nleZBnIfp/x0Od1QmWxEYnmtUWULoGFtGADJirM4+nJHbZASpSxN Mr8/RHHFBw/MNMUnyoA4rdK/KHDPRjdCiGSfdkcIo+xZOMTlGhDCFy3XMsu+XKbV bRu4lDseX3ecvtI9b9ORdD+9Z9/AMpH4rh+MQYxyNRSi/HlfX+FOizFrjhBzSpKR RSN6NzXIcl89zTlpZ7210f7Ox3K92cL/OyPMHXN+hmssQRdH35bai9XBbkVgy+vh Z6GXgZgZ9ce4JFfe0aTjjnA/3C9PFVUZw+ZQJy7MRQetiEtZbf0pdo6nyV65q7Bd AX+RuA== Received: from nasanppmta02.qualcomm.com (i-global254.qualcomm.com [199.106.103.254]) by mx0a-0031df01.pphosted.com (PPS) with ESMTPS id 406xpdm6bw-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 08 Jul 2024 17:59:34 +0000 (GMT) Received: from nasanex01b.na.qualcomm.com (nasanex01b.na.qualcomm.com [10.46.141.250]) by NASANPPMTA02.qualcomm.com (8.17.1.19/8.17.1.19) with ESMTPS id 468HxYUC019165 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 8 Jul 2024 17:59:34 GMT Received: from [10.110.78.14] (10.80.80.8) by nasanex01b.na.qualcomm.com (10.46.141.250) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1544.9; Mon, 8 Jul 2024 10:59:33 -0700 Message-ID: Date: Mon, 8 Jul 2024 10:59:33 -0700 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 5/8] firmware: arm_scmi: Make SMC transport a standalone driver To: Cristian Marussi CC: , , , , , , , , , , , , , , Peng Fan References: <20240707002055.1835121-1-cristian.marussi@arm.com> <20240707002055.1835121-6-cristian.marussi@arm.com> <273d23f5-c354-43cf-8903-d07f42778c3a@quicinc.com> Content-Language: en-US From: Nikunj Kela In-Reply-To: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Originating-IP: [10.80.80.8] X-ClientProxiedBy: nasanex01a.na.qualcomm.com (10.52.223.231) To nasanex01b.na.qualcomm.com (10.46.141.250) X-QCInternal: smtphost X-Proofpoint-Virus-Version: vendor=nai engine=6200 definitions=5800 signatures=585085 X-Proofpoint-GUID: MHIYSteg_QSIJGjSxqqsaGgYASLFjaAJ X-Proofpoint-ORIG-GUID: MHIYSteg_QSIJGjSxqqsaGgYASLFjaAJ X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.293,Aquarius:18.0.1039,Hydra:6.0.680,FMLib:17.12.28.16 definitions=2024-07-08_09,2024-07-05_01,2024-05-17_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 phishscore=0 impostorscore=0 adultscore=0 suspectscore=0 mlxscore=0 mlxlogscore=999 spamscore=0 clxscore=1015 lowpriorityscore=0 priorityscore=1501 malwarescore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.19.0-2406140001 definitions=main-2407080134 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20240708_105953_070290_053A9D74 X-CRM114-Status: GOOD ( 48.53 ) 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 7/8/2024 8:47 AM, Cristian Marussi wrote: > On Mon, Jul 08, 2024 at 08:23:56AM -0700, Nikunj Kela wrote: >> On 7/8/2024 7:27 AM, Cristian Marussi wrote: >>> On Sun, Jul 07, 2024 at 09:52:49AM -0700, Nikunj Kela wrote: >>>> On 7/6/2024 5:20 PM, Cristian Marussi wrote: >>>>> Make SCMI SMC transport a standalone driver that can be optionally >>>>> loaded as a module. >>>>> >>>>> CC: Peng Fan >>>>> CC: Nikunj Kela >>>>> Signed-off-by: Cristian Marussi >>>>> --- >>>>> drivers/firmware/arm_scmi/Kconfig | 4 ++- >>>>> drivers/firmware/arm_scmi/Makefile | 2 +- >>>>> drivers/firmware/arm_scmi/common.h | 3 -- >>>>> drivers/firmware/arm_scmi/driver.c | 5 --- >>>>> .../arm_scmi/{smc.c => scmi_transport_smc.c} | 31 +++++++++++++++---- >>>>> 5 files changed, 29 insertions(+), 16 deletions(-) >>>>> rename drivers/firmware/arm_scmi/{smc.c => scmi_transport_smc.c} (89%) >>>>> >>>>> diff --git a/drivers/firmware/arm_scmi/Kconfig b/drivers/firmware/arm_scmi/Kconfig >>>>> index 135e34aefd70..a4d44ef8bf45 100644 >>>>> --- a/drivers/firmware/arm_scmi/Kconfig >>>>> +++ b/drivers/firmware/arm_scmi/Kconfig >>>>> @@ -102,7 +102,7 @@ config ARM_SCMI_TRANSPORT_OPTEE >>>>> transport based on OP-TEE SCMI service, answer Y. >>>>> >>>>> config ARM_SCMI_TRANSPORT_SMC >>>>> - bool "SCMI transport based on SMC" >>>>> + tristate "SCMI transport based on SMC" >>>>> depends on HAVE_ARM_SMCCC_DISCOVERY >>>>> select ARM_SCMI_HAVE_TRANSPORT >>>>> select ARM_SCMI_HAVE_SHMEM >>>>> @@ -112,6 +112,8 @@ config ARM_SCMI_TRANSPORT_SMC >>>>> >>>>> If you want the ARM SCMI PROTOCOL stack to include support for a >>>>> transport based on SMC, answer Y. >>>>> + This driver can also be built as a module. If so, the module >>>>> + will be called scmi_transport_smc. >>>>> >>>>> config ARM_SCMI_TRANSPORT_SMC_ATOMIC_ENABLE >>>>> bool "Enable atomic mode support for SCMI SMC transport" >>>>> diff --git a/drivers/firmware/arm_scmi/Makefile b/drivers/firmware/arm_scmi/Makefile >>>>> index 121612d75f0b..6868a47fa4ab 100644 >>>>> --- a/drivers/firmware/arm_scmi/Makefile >>>>> +++ b/drivers/firmware/arm_scmi/Makefile >>>>> @@ -5,7 +5,6 @@ scmi-core-objs := $(scmi-bus-y) >>>>> scmi-driver-y = driver.o notify.o >>>>> scmi-driver-$(CONFIG_ARM_SCMI_RAW_MODE_SUPPORT) += raw_mode.o >>>>> scmi-transport-$(CONFIG_ARM_SCMI_HAVE_SHMEM) = shmem.o >>>>> -scmi-transport-$(CONFIG_ARM_SCMI_TRANSPORT_SMC) += smc.o >>>>> scmi-transport-$(CONFIG_ARM_SCMI_HAVE_MSG) += msg.o >>>>> scmi-transport-$(CONFIG_ARM_SCMI_TRANSPORT_VIRTIO) += virtio.o >>>>> scmi-transport-$(CONFIG_ARM_SCMI_TRANSPORT_OPTEE) += optee.o >>>>> @@ -13,6 +12,7 @@ scmi-protocols-y := base.o clock.o perf.o power.o reset.o sensors.o system.o vol >>>>> scmi-protocols-y += pinctrl.o >>>>> scmi-module-objs := $(scmi-driver-y) $(scmi-protocols-y) $(scmi-transport-y) >>>>> >>>>> +obj-$(CONFIG_ARM_SCMI_TRANSPORT_SMC) += scmi_transport_smc.o >>>>> obj-$(CONFIG_ARM_SCMI_TRANSPORT_MAILBOX) += scmi_transport_mailbox.o >>>>> >>>>> obj-$(CONFIG_ARM_SCMI_PROTOCOL) += scmi-core.o >>>>> diff --git a/drivers/firmware/arm_scmi/common.h b/drivers/firmware/arm_scmi/common.h >>>>> index c03f30db92e0..b5bd27eccf24 100644 >>>>> --- a/drivers/firmware/arm_scmi/common.h >>>>> +++ b/drivers/firmware/arm_scmi/common.h >>>>> @@ -286,9 +286,6 @@ int scmi_xfer_raw_inflight_register(const struct scmi_handle *handle, >>>>> int scmi_xfer_raw_wait_for_message_response(struct scmi_chan_info *cinfo, >>>>> struct scmi_xfer *xfer, >>>>> unsigned int timeout_ms); >>>>> -#ifdef CONFIG_ARM_SCMI_TRANSPORT_SMC >>>>> -extern const struct scmi_desc scmi_smc_desc; >>>>> -#endif >>>>> #ifdef CONFIG_ARM_SCMI_TRANSPORT_VIRTIO >>>>> extern const struct scmi_desc scmi_virtio_desc; >>>>> #endif >>>>> diff --git a/drivers/firmware/arm_scmi/driver.c b/drivers/firmware/arm_scmi/driver.c >>>>> index 96cf8ab4421e..b14c5326930a 100644 >>>>> --- a/drivers/firmware/arm_scmi/driver.c >>>>> +++ b/drivers/firmware/arm_scmi/driver.c >>>>> @@ -3254,11 +3254,6 @@ static const struct of_device_id scmi_of_match[] = { >>>>> #ifdef CONFIG_ARM_SCMI_TRANSPORT_OPTEE >>>>> { .compatible = "linaro,scmi-optee", .data = &scmi_optee_desc }, >>>>> #endif >>>>> -#ifdef CONFIG_ARM_SCMI_TRANSPORT_SMC >>>>> - { .compatible = "arm,scmi-smc", .data = &scmi_smc_desc}, >>>>> - { .compatible = "arm,scmi-smc-param", .data = &scmi_smc_desc}, >>>>> - { .compatible = "qcom,scmi-smc", .data = &scmi_smc_desc}, >>>>> -#endif >>>>> #ifdef CONFIG_ARM_SCMI_TRANSPORT_VIRTIO >>>>> { .compatible = "arm,scmi-virtio", .data = &scmi_virtio_desc}, >>>>> #endif >>>>> diff --git a/drivers/firmware/arm_scmi/smc.c b/drivers/firmware/arm_scmi/scmi_transport_smc.c >>>>> similarity index 89% >>>>> rename from drivers/firmware/arm_scmi/smc.c >>>>> rename to drivers/firmware/arm_scmi/scmi_transport_smc.c >>>>> index cb26b8aee01d..44da1a8d5387 100644 >>>>> --- a/drivers/firmware/arm_scmi/smc.c >>>>> +++ b/drivers/firmware/arm_scmi/scmi_transport_smc.c >>>>> @@ -3,7 +3,7 @@ >>>>> * System Control and Management Interface (SCMI) Message SMC/HVC >>>>> * Transport driver >>>>> * >>>>> - * Copyright 2020 NXP >>>>> + * Copyright 2020-2024 NXP >>>>> */ >>>>> >>>>> #include >>>>> @@ -16,6 +16,7 @@ >>>>> #include >>>>> #include >>>>> #include >>>>> +#include >>>>> #include >>>>> #include >>>>> >>>>> @@ -69,12 +70,14 @@ struct scmi_smc { >>>>> unsigned long cap_id; >>>>> }; >>>>> >>>>> +static struct scmi_transport_core_operations *core; >>>>> + >>>>> static irqreturn_t smc_msg_done_isr(int irq, void *data) >>>>> { >>>>> struct scmi_smc *scmi_info = data; >>>>> >>>>> - scmi_rx_callback(scmi_info->cinfo, >>>>> - scmi_shmem_ops.read_header(scmi_info->shmem), NULL); >>>>> + core->rx_callback(scmi_info->cinfo, >>>>> + core->shmem->read_header(scmi_info->shmem), NULL); >>>>> >>>>> return IRQ_HANDLED; >>>>> } >>>>> @@ -142,7 +145,7 @@ static int smc_chan_setup(struct scmi_chan_info *cinfo, struct device *dev, >>>>> if (!scmi_info) >>>>> return -ENOMEM; >>>>> >>>>> - scmi_info->shmem = scmi_shmem_ops.setup_iomap(cinfo, dev, tx); >>>>> + scmi_info->shmem = core->shmem->setup_iomap(cinfo, dev, tx); >>>>> if (IS_ERR(scmi_info->shmem)) >>>>> return PTR_ERR(scmi_info->shmem); >>>>> >>>>> @@ -226,7 +229,7 @@ static int smc_send_message(struct scmi_chan_info *cinfo, >>>>> */ >>>>> smc_channel_lock_acquire(scmi_info, xfer); >>>>> >>>>> - scmi_shmem_ops.tx_prepare(scmi_info->shmem, xfer, cinfo); >>>>> + core->shmem->tx_prepare(scmi_info->shmem, xfer, cinfo); >>>>> >>>>> if (scmi_info->cap_id != ULONG_MAX) >>>>> arm_smccc_1_1_invoke(scmi_info->func_id, scmi_info->cap_id, 0, >>>>> @@ -250,7 +253,7 @@ static void smc_fetch_response(struct scmi_chan_info *cinfo, >>>>> { >>>>> struct scmi_smc *scmi_info = cinfo->transport_info; >>>>> >>>>> - scmi_shmem_ops.fetch_response(scmi_info->shmem, xfer); >>>>> + core->shmem->fetch_response(scmi_info->shmem, xfer); >>>>> } >>>>> >>>>> static void smc_mark_txdone(struct scmi_chan_info *cinfo, int ret, >>>>> @@ -286,3 +289,19 @@ const struct scmi_desc scmi_smc_desc = { >>>>> .sync_cmds_completed_on_ret = true, >>>>> .atomic_enabled = IS_ENABLED(CONFIG_ARM_SCMI_TRANSPORT_SMC_ATOMIC_ENABLE), >>>>> }; >>>>> + >>>>> +static const struct of_device_id scmi_of_match[] = { >>>>> + { .compatible = "arm,scmi-smc" }, >>>>> + { .compatible = "arm,scmi-smc-param" }, >>>>> + { .compatible = "qcom,scmi-smc" }, >>>>> + { /* Sentinel */ }, >>>>> +}; >>>>> + >>>> Hi Cristian, >>>> >>> Hi Nikunj, >>> >>> thanks for having a look first of all ! >>> >>>> Would it make sense to associate scmi descriptor(scmi_smc_desc) with >>>> compatible as driver/platform data so we have flexibility to replicate >>>> it and modify parameters such as max_timeout_ms etc. for our platform? >>>> >>> Mmmm...not sure to have understood, because the scmi_smc_desc is >>> effecetively passed from this driver to the core via a bit of >>> (questionable) magic in the mega-macro >>> >>> DEFINE_SCMI_TRANSPORT_DRIVER(scmi_smc, scmi_of_match, &core); >>> >>> ...and it will end-up being set into the dev.platform_data and then >>> retrieved by the core SCMI stack driver in scmi_probe... >>> >>> ...OR...do you mean being able to somehow define 3 different >>> scmi_smc_desc* and then associate them to the different compatibles >>> and then, depending on which compatible is matched by this isame driver >>> at probe time, passing the related platform-specific desc to the core... >>> >>> ...in this latter case I suppose I can do it by playing with the macros >>> defs but maybe it is also the case to start thinking about splitting out >>> configuration stuff from the transport descriptor... >>> >>> I'll give it a go at passing the data around, and see how it plays out >>> if you confirm that this is what you meant... >> Hi Cristian, >> > Hi, > >> I wanted to send a patch for review(with older driver code) that will >> allow us to override transport parameters(e.g. max_timeout_ms, >> max_msg_size etc.) on Qualcomm platform. There could be multiple >> approaches- 1) add callbacks (similar to get_msg_size) in transport_ops >> and override the default or 2) replicate the descriptors for different >> compatible and change those values as needed. I was going with the >> second option but then I saw your patch and thought of throwing this at > :P > >> you ;) I don't want you to hold your patch series for this but if you >> have a better way to achieve or a preferred way between the two >> mentioned before, please let me know. If you do want to add this feature >> in this patch series, that would be great! >> > Interesting, because there is also this thread flying around from Peng: > > https://lore.kernel.org/linux-arm-kernel/20240703031715.379815-1-peng.fan@oss.nxp.com/ Thanks Cristian for the link. I was under the impression that DT binding that don't describe HW are not acceptable to DT maintainer. But if this patch goes through, I am fine using it. I would also like to have max_msg_size(and maybe max_msg) configurable. > > ...which I was planning in embedding in this series; Peng's proposal is > limited to timeout and based on DT (and title is a bit misleading...the > series is not mailbox-only related).... > > ...now I am NOT saying that we should dump all configs into the DT, but > just that this issue about configurability of transports is already sort > of a known-problem, and it is a while that it floats in the back of my mind... > i.e. the fact that the transport runtime configurations should be *somehow* > independent of the transport descriptor and *somehow* configurable....so now > only remains to *somehow* figure out how to do it :D > > ... I'll have a though and maybe cannibalize your ideas and Peng's one and then > we could have a discussion around this on the list to address eveybody's needs... > > ...and maybe, in the meantime, you could also post your proposed series about > this even though based on the old code, but as an RFC, just to make a point and > detail the needs...but yeah only if it does not require a bunch of extra work from > you given that it is only to be used as a basis for discussion .... > > ...up to you what do you prefer. > > Thanks, > Cristian