From: Sudeep Holla <sudeep.holla@arm.com>
To: Nikunj Kela <quic_nkela@quicinc.com>
Cc: cristian.marussi@arm.com, robh+dt@kernel.org,
Sudeep Holla <sudeep.holla@arm.com>,
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
Date: Tue, 11 Apr 2023 14:01:36 +0100 [thread overview]
Message-ID: <20230411130136.lkblyfg3jaeitzrt@bogus> (raw)
In-Reply-To: <20230410182058.8949-1-quic_nkela@quicinc.com>
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
next prev parent reply other threads:[~2023-04-11 13:02 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-04-09 18:19 [PATCH 0/2] Allow parameter in smc/hvc calls Nikunj Kela
2023-04-09 18:19 ` [PATCH 1/2] dt-bindings: firmware: arm,scmi: support parameter passing in smc/hvc Nikunj Kela
2023-04-10 17:20 ` Krzysztof Kozlowski
2023-04-10 17:33 ` Nikunj Kela
2023-04-11 17:17 ` Krzysztof Kozlowski
2023-04-09 18:19 ` [PATCH 2/2] firmware: arm_scmi: Augment SMC/HVC to allow optional parameters Nikunj Kela
2023-04-09 22:22 ` kernel test robot
2023-04-10 18:20 ` [PATCH v2 0/2] Allow parameter in smc/hvc calls Nikunj Kela
2023-04-10 18:20 ` [PATCH v2 1/2] dt-bindings: firmware: arm,scmi: support parameter passing in smc/hvc Nikunj Kela
2023-04-11 12:54 ` Sudeep Holla
2023-04-11 14:46 ` Nikunj Kela
2023-04-11 17:18 ` Krzysztof Kozlowski
2023-04-11 17:25 ` Nikunj Kela
2023-04-10 18:20 ` [PATCH v2 2/2] firmware: arm_scmi: Augment SMC/HVC to allow optional parameters Nikunj Kela
2023-04-11 13:01 ` Sudeep Holla [this message]
2023-04-11 14:42 ` [PATCH v2 0/2] Allow parameter in smc/hvc calls Nikunj Kela
2023-04-12 8:37 ` Sudeep Holla
2023-04-12 14:54 ` Nikunj Kela
2023-04-17 17:43 ` [PATCH v3 " Nikunj Kela
2023-04-17 17:44 ` [PATCH v3 1/2] dt-bindings: firmware: arm,scmi: support for parameter in smc/hvc call Nikunj Kela
2023-04-17 17:44 ` [PATCH v3 2/2] firmware: arm_scmi: Augment SMC/HVC to allow optional parameter Nikunj Kela
2023-04-17 18:01 ` Florian Fainelli
2023-04-17 18:17 ` Nikunj Kela
2023-04-18 9:58 ` Sudeep Holla
2023-04-18 14:20 ` Nikunj Kela
2023-04-18 16:33 ` Florian Fainelli
2023-04-18 17:07 ` Nikunj Kela
2023-04-18 18:56 ` [PATCH v4 0/2] Allow parameter in smc/hvc calls Nikunj Kela
2023-04-18 18:56 ` [PATCH v4 1/2] dt-bindings: firmware: arm,scmi: support for parameter in smc/hvc call Nikunj Kela
2023-04-25 16:50 ` Rob Herring
2023-04-18 18:56 ` [PATCH v4 2/2] firmware: arm_scmi: Augment SMC/HVC to allow optional parameters Nikunj Kela
2023-05-01 14:39 ` Nikunj Kela
2023-05-02 10:46 ` Sudeep Holla
2023-05-02 14:41 ` Nikunj Kela
2023-04-25 14:01 ` [PATCH v4 0/2] Allow parameter in smc/hvc calls Nikunj Kela
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20230411130136.lkblyfg3jaeitzrt@bogus \
--to=sudeep.holla@arm.com \
--cc=cristian.marussi@arm.com \
--cc=devicetree@vger.kernel.org \
--cc=krzysztof.kozlowski+dt@linaro.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=lkp@intel.com \
--cc=quic_nkela@quicinc.com \
--cc=robh+dt@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).