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;
Message-ID: <d1d98ad5-73f0-e42d-70ef-804c945f70cc@quicinc.com>
Date:   Wed, 19 Jul 2023 06:58:45 -0700
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101
 Thunderbird/102.10.0
Subject: Re: [PATCH 1/2] dt-bindings: arm: Add qcom specific hvc transport for
 SCMI
To:     Sudeep Holla <sudeep.holla@arm.com>
CC:     <cristian.marussi@arm.com>, <robh+dt@kernel.org>,
        <krzysztof.kozlowski+dt@linaro.org>, <conor+dt@kernel.org>,
        <agross@kernel.org>, <andersson@kernel.org>,
        <konrad.dybcio@linaro.org>, <linux-arm-kernel@lists.infradead.org>,
        <devicetree@vger.kernel.org>, <linux-kernel@vger.kernel.org>,
        <linux-arm-msm@vger.kernel.org>
References: <20230718160833.36397-1-quic_nkela@quicinc.com>
 <20230718160833.36397-2-quic_nkela@quicinc.com>
 <20230719103917.f4dnsujub7pfqr26@bogus>
Content-Language: en-US
From:   Nikunj Kela <quic_nkela@quicinc.com>
In-Reply-To: <20230719103917.f4dnsujub7pfqr26@bogus>
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: 7bit
Precedence: bulk


On 7/19/2023 3:39 AM, Sudeep Holla wrote:
> On Tue, Jul 18, 2023 at 09:08:32AM -0700, Nikunj Kela wrote:
>> Introduce compatible "qcom,scmi-hvc-shmem" for SCMI
>> transport channel for Qualcomm virtual platforms.
>> The compatible mandates a shared memory channel.
>>
>> Signed-off-by: Nikunj Kela <quic_nkela@quicinc.com>
>> ---
>>   .../bindings/firmware/arm,scmi.yaml           | 69 +++++++++++++++++++
>>   1 file changed, 69 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/firmware/arm,scmi.yaml b/Documentation/devicetree/bindings/firmware/arm,scmi.yaml
>> index b138f3d23df8..605b1e997a85 100644
>> --- a/Documentation/devicetree/bindings/firmware/arm,scmi.yaml
>> +++ b/Documentation/devicetree/bindings/firmware/arm,scmi.yaml
>> @@ -45,6 +45,9 @@ properties:
>>         - description: SCMI compliant firmware with OP-TEE transport
>>           items:
>>             - const: linaro,scmi-optee
>> +      - description: SCMI compliant firmware with Qualcomm hvc/shmem transport
>> +        items:
>> +          - const: qcom,scmi-hvc-shmem
>>   
>>     interrupts:
>>       description:
>> @@ -321,6 +324,16 @@ else:
>>         required:
>>           - linaro,optee-channel-id
>>   
>> +    else:
>> +      if:
>> +        properties:
>> +          compatible:
>> +            contains:
>> +              const: qcom,scmi-hvc-shmem
>> +      then:
>> +        required:
>> +          - shmem
>> +
> Since this was done after we merged the support recently for extension of
> SMC/HVC, I need the reason(s) why this can't be used and based on the response
> this is new change so it can't be because there is a product already
> supporting this. So for now, NACK until I get the response for these.
Our hypervisor deals with objects and uses object-ids to identify them. 
The hvc doorbell object is independent of the shmem object created by 
hypervisor. Hypervisor treats them independently. With the patch you 
mentioned, hypervisor need to create an association between the doorbell 
object and shmem object which will make it SCMI specific change in 
hypervisor. Hypervisor doesn't really care if doorbell is for SCMI or 
for other purposes hence we are adding this new driver so it can work 
with our hypervisor ABIs specification.