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 A0028C77B6F for ; Tue, 11 Apr 2023 13:02:49 +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=VCluNQoFOR5pUgqShssN9WtQB4ofrQCHQBnOTsZ2/70=; b=MKFe5/CxkaNQ3/ UxDpAmvPPGN5bEJ6Bx7QcL44guAXGWjLXvd8sPvvtapwSFU3yNLAnMFyLj5jt1yiI3e59TW+rpDi2 stFobF9Y62BRUG2mzLXiUrQrWCMKer/IU0KhRNQfzg3sk3pRMsQKA6rbBD/65rxwmY/43Ab/nf6kR Cljse243IntcUfFpPdygG+RjWVvVb8MNDFZkpPL3NdF+T0Y5WkkOjLo1ww04Wt72/h5gvrbt23GX6 cXAgmuVE6fOyL5sR8v6AlysErBvQRyrhyBfaIdtwP/wijRFWrd1oj8GTuaXXRho7PF7+qqGFaVo33 U+wFK5rUd9/6FH6m78XQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.96 #2 (Red Hat Linux)) id 1pmDdF-0002T0-1p; Tue, 11 Apr 2023 13:01:57 +0000 Received: from foss.arm.com ([217.140.110.172]) by bombadil.infradead.org with esmtp (Exim 4.96 #2 (Red Hat Linux)) id 1pmDd9-0002Py-1e for linux-arm-kernel@lists.infradead.org; Tue, 11 Apr 2023 13:01:55 +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 E4ECFD75; Tue, 11 Apr 2023 06:02:24 -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 5089D3F6C4; Tue, 11 Apr 2023 06:01:39 -0700 (PDT) Date: Tue, 11 Apr 2023 14:01:36 +0100 From: Sudeep Holla To: Nikunj Kela Cc: cristian.marussi@arm.com, robh+dt@kernel.org, Sudeep Holla , krzysztof.kozlowski+dt@linaro.org, linux-arm-kernel@lists.infradead.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, lkp@intel.com Subject: Re: [PATCH v2 0/2] Allow parameter in smc/hvc calls Message-ID: <20230411130136.lkblyfg3jaeitzrt@bogus> References: <20230409181918.29270-1-quic_nkela@quicinc.com> <20230410182058.8949-1-quic_nkela@quicinc.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20230410182058.8949-1-quic_nkela@quicinc.com> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20230411_060151_596714_910F3799 X-CRM114-Status: GOOD ( 16.80 ) 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 Mon, Apr 10, 2023 at 11:20:56AM -0700, Nikunj Kela wrote: > Currently, smc/hvc calls are made with parameters set > to zeros. We are using multiple scmi instances within > a VM and hypervisor associates a tag with each instance > and expects the tag in hvc calls from that instance, while > sharing the same smc-id(func_id) among the instances. > > This patch series introduces new optional dtb bindings which > can be used to pass parameters to smc/hvc calls. > Just to be sure that I understood the problem(as your 2 parameters confused me), this is just to help hypervisor/secure side to identify the right channel/shared memory when the same SMC/HVC function id is shared right ? If that is the case, why can't we just pass the shmem address as the parameter ? I would like to avoid fragmentation here with every vendor trying to do different things to achieve the same. I would just change the driver to do that. Not sure if it breaks any existing implementation or not. If it does, we can add another compatible to identify one needing this fixed(shmem address) as additional parameter. Does that make sense at all ? Or am I missing some/all of the requirements here ? -- Regards, Sudeep _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel