Document the compatible for Qualcomm SM6375 SCM.
Signed-off-by: Konrad Dybcio <[email protected]>
---
Documentation/devicetree/bindings/firmware/qcom,scm.yaml | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/firmware/qcom,scm.yaml b/Documentation/devicetree/bindings/firmware/qcom,scm.yaml
index c5b76c9f7ad0..abcb1fae9eb2 100644
--- a/Documentation/devicetree/bindings/firmware/qcom,scm.yaml
+++ b/Documentation/devicetree/bindings/firmware/qcom,scm.yaml
@@ -47,6 +47,7 @@ properties:
- qcom,scm-sm6115
- qcom,scm-sm6125
- qcom,scm-sm6350
+ - qcom,scm-sm6375
- qcom,scm-sm8150
- qcom,scm-sm8250
- qcom,scm-sm8350
--
2.37.3
On 21/09/2022 02:10, Konrad Dybcio wrote:
> Document the compatible for Qualcomm SM6375 SCM.
>
> Signed-off-by: Konrad Dybcio <[email protected]>
> ---
> Documentation/devicetree/bindings/firmware/qcom,scm.yaml | 1 +
allOf needs to be updated.
Best regards,
Krzysztof
On 21.09.2022 09:07, Krzysztof Kozlowski wrote:
> On 21/09/2022 02:10, Konrad Dybcio wrote:
>> Document the compatible for Qualcomm SM6375 SCM.
>>
>> Signed-off-by: Konrad Dybcio <[email protected]>
>> ---
>> Documentation/devicetree/bindings/firmware/qcom,scm.yaml | 1 +
>
> allOf needs to be updated.
Does it? I did not define this compatible in the driver, so it does
not consume any clocks.
Konrad
>
>
> Best regards,
> Krzysztof
On 21/09/2022 20:43, Konrad Dybcio wrote:
>
>
> On 21.09.2022 09:07, Krzysztof Kozlowski wrote:
>> On 21/09/2022 02:10, Konrad Dybcio wrote:
>>> Document the compatible for Qualcomm SM6375 SCM.
>>>
>>> Signed-off-by: Konrad Dybcio <[email protected]>
>>> ---
>>> Documentation/devicetree/bindings/firmware/qcom,scm.yaml | 1 +
>>
>> allOf needs to be updated.
> Does it? I did not define this compatible in the driver, so it does
> not consume any clocks.
It's about hardware, not driver. Hardware has some clocks. If it does
not, then you need allOf disallowing it. Otherwise what do you expect in
the clock entries?
Best regards,
Krzysztof
On 21.09.2022 21:06, Krzysztof Kozlowski wrote:
> On 21/09/2022 20:43, Konrad Dybcio wrote:
>>
>>
>> On 21.09.2022 09:07, Krzysztof Kozlowski wrote:
>>> On 21/09/2022 02:10, Konrad Dybcio wrote:
>>>> Document the compatible for Qualcomm SM6375 SCM.
>>>>
>>>> Signed-off-by: Konrad Dybcio <[email protected]>
>>>> ---
>>>> Documentation/devicetree/bindings/firmware/qcom,scm.yaml | 1 +
>>>
>>> allOf needs to be updated.
>> Does it? I did not define this compatible in the driver, so it does
>> not consume any clocks.
>
> It's about hardware, not driver. Hardware has some clocks. If it does
> not, then you need allOf disallowing it. Otherwise what do you expect in
> the clock entries?
Ok, so if I understand correctly then, all the compatibles that are in
the long long list in /properties/compatible/enum: should also be added
somewhere in the allOf: tree?
Konrad
>
> Best regards,
> Krzysztof
>
On 21/09/2022 23:07, Konrad Dybcio wrote:
>>>> allOf needs to be updated.
>>> Does it? I did not define this compatible in the driver, so it does
>>> not consume any clocks.
>>
>> It's about hardware, not driver. Hardware has some clocks. If it does
>> not, then you need allOf disallowing it. Otherwise what do you expect in
>> the clock entries?
> Ok, so if I understand correctly then, all the compatibles that are in
> the long long list in /properties/compatible/enum: should also be added
> somewhere in the allOf: tree?
Yes, because the clocks must be specific/fixed.
Best regards,
Krzysztof
On Sep 21 2022 20:43, Konrad Dybcio wrote:
> Does it? I did not define this compatible in the driver, so it does
> not consume any clocks.
The bindings should describe only those compatibles that the driver supports -
that is, both the driver and its bindings should be in sync.
Could you please update the driver with this compatible as well? Let's not
merge this change without that first.
Thank you.
Guru Das.
On 24/09/2022 02:09, Guru Das Srinagesh wrote:
> On Sep 21 2022 20:43, Konrad Dybcio wrote:
>> Does it? I did not define this compatible in the driver, so it does
>> not consume any clocks.
>
> The bindings should describe only those compatibles that the driver supports -
> that is, both the driver and its bindings should be in sync.
That's not entirely true. Bindings describe the hardware in the most
complete way we can. Not the driver. Whether driver supports something
or not, is not relevant here, except that we don't want to document
non-existing things or stuff out of tree.
>
> Could you please update the driver with this compatible as well? Let's not
> merge this change without that first.
This could be even merged without change in the driver. However it's not
the case here as driver already supports it, so your request is fulfilled.
Best regards,
Krzysztof
On Sep 24 2022 10:17, Krzysztof Kozlowski wrote:
> On 24/09/2022 02:09, Guru Das Srinagesh wrote:
> > On Sep 21 2022 20:43, Konrad Dybcio wrote:
> >> Does it? I did not define this compatible in the driver, so it does
> >> not consume any clocks.
> >
> > The bindings should describe only those compatibles that the driver supports -
> > that is, both the driver and its bindings should be in sync.
>
> That's not entirely true. Bindings describe the hardware in the most
> complete way we can. Not the driver. Whether driver supports something
> or not, is not relevant here, except that we don't want to document
> non-existing things or stuff out of tree.
Is this only applicable to compatibles or device tree properties in general?
> >
> > Could you please update the driver with this compatible as well? Let's not
> > merge this change without that first.
>
> This could be even merged without change in the driver. However it's not
> the case here as driver already supports it, so your request is fulfilled.
My concern is that if somebody specifies a compatible/device tree property that
the driver doesn't support, their expectations from adding that change will not
be met. In addition to having the bindings describe HW in full, I think the
driver should also be in sync with it for this reason.
Thank you.
Guru Das.
On Mon, Sep 26, 2022 at 09:59:04AM -0700, Guru Das Srinagesh wrote:
> On Sep 24 2022 10:17, Krzysztof Kozlowski wrote:
> > On 24/09/2022 02:09, Guru Das Srinagesh wrote:
> > > On Sep 21 2022 20:43, Konrad Dybcio wrote:
> > >> Does it? I did not define this compatible in the driver, so it does
> > >> not consume any clocks.
> > >
> > > The bindings should describe only those compatibles that the driver supports -
> > > that is, both the driver and its bindings should be in sync.
> >
> > That's not entirely true. Bindings describe the hardware in the most
> > complete way we can. Not the driver. Whether driver supports something
> > or not, is not relevant here, except that we don't want to document
> > non-existing things or stuff out of tree.
>
> Is this only applicable to compatibles or device tree properties in general?
>
> > >
> > > Could you please update the driver with this compatible as well? Let's not
> > > merge this change without that first.
> >
> > This could be even merged without change in the driver. However it's not
> > the case here as driver already supports it, so your request is fulfilled.
>
> My concern is that if somebody specifies a compatible/device tree property that
> the driver doesn't support, their expectations from adding that change will not
> be met. In addition to having the bindings describe HW in full, I think the
> driver should also be in sync with it for this reason.
Which driver? From u-boot, *BSD, Linux, TF-A, ...?
Rob
On 26/09/2022 18:59, Guru Das Srinagesh wrote:
> On Sep 24 2022 10:17, Krzysztof Kozlowski wrote:
>> On 24/09/2022 02:09, Guru Das Srinagesh wrote:
>>> On Sep 21 2022 20:43, Konrad Dybcio wrote:
>>>> Does it? I did not define this compatible in the driver, so it does
>>>> not consume any clocks.
>>>
>>> The bindings should describe only those compatibles that the driver supports -
>>> that is, both the driver and its bindings should be in sync.
>>
>> That's not entirely true. Bindings describe the hardware in the most
>> complete way we can. Not the driver. Whether driver supports something
>> or not, is not relevant here, except that we don't want to document
>> non-existing things or stuff out of tree.
>
> Is this only applicable to compatibles or device tree properties in general?
This applies to everything.
>
>>>
>>> Could you please update the driver with this compatible as well? Let's not
>>> merge this change without that first.
>>
>> This could be even merged without change in the driver. However it's not
>> the case here as driver already supports it, so your request is fulfilled.
>
> My concern is that if somebody specifies a compatible/device tree property that
> the driver doesn't support, their expectations from adding that change will not
> be met. In addition to having the bindings describe HW in full, I think the
> driver should also be in sync with it for this reason.
As Rob answered, it might be difficult to keep all drivers in all
operating systems, bootloaders and firmware components to be in sync. :)
Best regards,
Krzysztof
On Sep 27 2022 13:42, Krzysztof Kozlowski wrote:
> On 26/09/2022 18:59, Guru Das Srinagesh wrote:
> > On Sep 24 2022 10:17, Krzysztof Kozlowski wrote:
> >> On 24/09/2022 02:09, Guru Das Srinagesh wrote:
> >>> On Sep 21 2022 20:43, Konrad Dybcio wrote:
> >>>> Does it? I did not define this compatible in the driver, so it does
> >>>> not consume any clocks.
> >>>
> >>> The bindings should describe only those compatibles that the driver supports -
> >>> that is, both the driver and its bindings should be in sync.
> >>
> >> That's not entirely true. Bindings describe the hardware in the most
> >> complete way we can. Not the driver. Whether driver supports something
> >> or not, is not relevant here, except that we don't want to document
> >> non-existing things or stuff out of tree.
> >
> > Is this only applicable to compatibles or device tree properties in general?
>
> This applies to everything.
>
> >
> >>>
> >>> Could you please update the driver with this compatible as well? Let's not
> >>> merge this change without that first.
> >>
> >> This could be even merged without change in the driver. However it's not
> >> the case here as driver already supports it, so your request is fulfilled.
> >
> > My concern is that if somebody specifies a compatible/device tree property that
> > the driver doesn't support, their expectations from adding that change will not
> > be met. In addition to having the bindings describe HW in full, I think the
> > driver should also be in sync with it for this reason.
>
> As Rob answered, it might be difficult to keep all drivers in all
> operating systems, bootloaders and firmware components to be in sync. :)
Ack.