| Message ID | 20220921001020.55307-1-konrad.dybcio@somainline.org (mailing list archive) |
|---|---|
| State | Superseded |
| Headers | show |
| Series | dt-bindings: firmware: document Qualcomm SM6375 SCM | expand |
On 21/09/2022 02:10, Konrad Dybcio wrote: > Document the compatible for Qualcomm SM6375 SCM. > > Signed-off-by: Konrad Dybcio <konrad.dybcio@somainline.org> > --- > 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 <konrad.dybcio@somainline.org> >> --- >> 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 <konrad.dybcio@somainline.org> >>> --- >>> 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 <konrad.dybcio@somainline.org> >>>> --- >>>> 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.
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
Document the compatible for Qualcomm SM6375 SCM. Signed-off-by: Konrad Dybcio <konrad.dybcio@somainline.org> --- Documentation/devicetree/bindings/firmware/qcom,scm.yaml | 1 + 1 file changed, 1 insertion(+)