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@xxxxxxxxxx> >>> --- >>> 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
