linux-kernel - Re: [PATCH 1/2] dt-bindings: firmware: arm,scmi: support parameter passing in smc/hvc

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Mon, 10 Apr 2023 10:33:52 -0700
From:   Nikunj Kela <quic_nkela@...cinc.com>
To:     Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>,
        <sudeep.holla@....com>
CC:     <cristian.marussi@....com>, <robh+dt@...nel.org>,
        <krzysztof.kozlowski+dt@...aro.org>,
        <linux-arm-kernel@...ts.infradead.org>,
        <devicetree@...r.kernel.org>, <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 1/2] dt-bindings: firmware: arm,scmi: support parameter
 passing in smc/hvc


On 4/10/2023 10:20 AM, Krzysztof Kozlowski wrote:
> On 09/04/2023 20:19, Nikunj Kela wrote:
>> Currently, smc/hvc calls are made with smc-id only. The parameters are
>> all set to zeros. This patch defines two optional device tree bindings,
>> that can be used to pass parameters in smc/hvc calls.
>>
>> This is useful when multiple scmi instances are used with common smc-id.
>>
>> Signed-off-by: Nikunj Kela <quic_nkela@...cinc.com>
>> ---
>>   .../devicetree/bindings/firmware/arm,scmi.yaml   | 16 ++++++++++++++++
>>   1 file changed, 16 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/firmware/arm,scmi.yaml b/Documentation/devicetree/bindings/firmware/arm,scmi.yaml
>> index 5824c43e9893..08c331a79b80 100644
>> --- a/Documentation/devicetree/bindings/firmware/arm,scmi.yaml
>> +++ b/Documentation/devicetree/bindings/firmware/arm,scmi.yaml
>> @@ -115,6 +115,22 @@ properties:
>>       description:
>>         SMC id required when using smc or hvc transports
>>   
>> +  arm,smc32-params:
>> +    $ref: /schemas/types.yaml#/definitions/uint32-array
>> +    description:
>> +      An optional parameter list passed in smc32 or hvc32 calls
>> +    default: 0
>> +    minItems: 1
>> +    maxItems: 6
>> +
>> +  arm,smc64-params:
>> +    $ref: /schemas/types.yaml#/definitions/uint64-array
>> +    description:
>> +      An optional parameter list passed in smc64 or hvc64 calls
>> +    default: 0
>> +    minItems: 1
>> +    maxItems: 6
> These do not look like hardware properties and the fact that you need
> two properties for the same also points that you tied it to specific SW
> interface.

This is certainly not the H/W property but then smc-id is also not H/W 
property either

but that gets passed via DTB. I could use the same property for both 
however I wasn't sure

which datatype should be used, uint32-array/uint64-array. Moreover, I 
thought if users are

passing parameters, they better know which SMC convention they are using 
hence used two

explicit properties.

> Why this should be board-specific? Actually better question - why this
> should be fixed per board? Doesn't my software want to have different
> parameters, depending on some other condition?

Not sure I follow, I didn't say this is board specific. People can use 
the parameters to pass

whatever their S/W demands. SMC/HVC calls are made by passing parameters 
which is what this patch is enabling.

>
> You also did not provide any DTS user for this, so difficult to judge
> usefulness.

The work is still on going and we will push the dts in few months, 
however that shouldn't stop

making changes in advance.

> Best regards,
> Krzysztof
>