On Mon, Oct 09, 2023 at 10:49:44AM -0700, Nikunj Kela wrote:
On 10/9/2023 8:29 AM, Sudeep Holla wrote:Thanks, since I have patched a bit, it is better if you post them so that
On Mon, Oct 09, 2023 at 07:59:08AM -0700, Nikunj Kela wrote:Validated the patch from [1] below on Qualcomm ARM64 virtual platform using
On 10/9/2023 7:47 AM, Sudeep Holla wrote:Please refer or use the patch from [1] when reposting. I rebased on my
On Fri, Oct 06, 2023 at 09:42:06AM -0700, Nikunj Kela wrote:This looks good to me. Will do some testing and float v6 with the changes
This change adds the support for SCMI message exchange on QualcommSince you are happy to move to signed value, I assume you are happy to loose
virtual platforms.
The hypervisor associates an object-id also known as capability-id
with each smc/hvc doorbell object. The capability-id is used to
identify the doorbell from the VM's capability namespace, similar
to a file-descriptor.
The hypervisor, in addition to the function-id, expects the capability-id
to be passed in x1 register when SMC/HVC call is invoked.
The capability-id is allocated by the hypervisor on bootup and is stored in
the shmem region by the firmware before starting Linux.
upper half of the range values ?
Anyways after Bjorn pointed out inconsistency, I am thinking of moving
all the values to unsigned long to work with both 32bit and 64bit.
Does the below delta on top of this patch works for you and makes sense?
you suggested below. Thanks
patch[2] that I posted few minutes back. I am trying to finalise the branch
and send PR in next couple of days, so please test and post sooner. Sorry
for the rush.
SMC64 convention. Thanks!
we have a link for the exact patch on the list. Just pick up the patches
from the branch[1] and post them as v6 with a change log so that all the
details are captured for reference purposes.