[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <f6c4f47d-8a08-fcff-9d68-d905942f0d83@linaro.org>
Date: Mon, 9 Jan 2023 11:31:13 +0100
From: Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>
To: Konrad Dybcio <konrad.dybcio@...aro.org>,
linux-arm-msm@...r.kernel.org, andersson@...nel.org,
agross@...nel.org
Cc: marijn.suijten@...ainline.org, Rob Herring <robh+dt@...nel.org>,
Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
devicetree@...r.kernel.org, linux-kernel@...r.kernel.org,
AngeloGioacchino Del Regno
<angelogioacchino.delregno@...ainline.org>,
Stephan Gerhold <stephan@...hold.net>,
Loic Poulain <loic.poulain@...aro.org>
Subject: Re: [PATCH v3 3/3] dt-bindings: firmware: qcom: scm: Separate VMIDs
from header to bindings
On 09/01/2023 11:16, Konrad Dybcio wrote:
>
>
> On 9.01.2023 10:54, Krzysztof Kozlowski wrote:
>> On 09/01/2023 10:39, Konrad Dybcio wrote:
>>> With changes to the rmtfs binding, secure VMIDs will become useful to
>>> have in device trees. Separate them out and add to include/dt-bindings.
>>>
>>> Signed-off-by: Konrad Dybcio <konrad.dybcio@...aro.org>
>>> ---
>>> v2 -> v3:
>>> New patch
>>>
>>> include/dt-bindings/firmware/qcom/scm.h | 16 ++++++++++++++++
>>> include/linux/qcom_scm.h | 7 ++-----
>>> 2 files changed, 18 insertions(+), 5 deletions(-)
>>> create mode 100644 include/dt-bindings/firmware/qcom/scm.h
>>>
>>> diff --git a/include/dt-bindings/firmware/qcom/scm.h b/include/dt-bindings/firmware/qcom/scm.h
>>> new file mode 100644
>>> index 000000000000..d66818cd57a8
>>> --- /dev/null
>>> +++ b/include/dt-bindings/firmware/qcom/scm.h
>>> @@ -0,0 +1,16 @@
>>> +/* SPDX-License-Identifier: GPL-2.0-only */
>>
>> Only Codeaurora folks contributed these numbers, thus we can relicense
>> it to dual-license, I believe.
>>
>> The other topic is what do these numbers represent: hardware interface?
>> registers? offsets? firmware?
> Arguments for a SCM call, so firmware interface.
>
> IOW, why bindings is the place for them?
>> (usefulness for DTS is not the reason)
> These defines correspond to mappings in a hardcoded, irreplaceable
> and un-omittable firmware which is (unless you steal engineering
> samples from the factory) always shipped with these SoCs and they
> help clarify some otherwise totally magic numbers.
OK, makes sense. Please mention this in commit msg to justify adding
them to bindings.
Best regards,
Krzysztof
Powered by blists - more mailing lists