diff mbox series

[1/5] dt-bindings: firmware: scm: Add QDU1000/QRU1000 compatibles

Message ID 20221001030641.29354-2-quic_molvera@quicinc.com
State New
Headers show
Series [1/5] dt-bindings: firmware: scm: Add QDU1000/QRU1000 compatibles | expand

Commit Message

Melody Olvera Oct. 1, 2022, 3:06 a.m. UTC
Add compatibles for scm driver for QDU1000 and QRU1000 platforms.

Signed-off-by: Melody Olvera <quic_molvera@quicinc.com>
---
 Documentation/devicetree/bindings/firmware/qcom,scm.yaml | 2 ++
 1 file changed, 2 insertions(+)

Comments

Melody Olvera Oct. 3, 2022, 10:02 p.m. UTC | #1
On 10/1/2022 4:25 AM, Krzysztof Kozlowski wrote:
> On 01/10/2022 05:06, Melody Olvera wrote:
>> Add compatibles for scm driver for QDU1000 and QRU1000 platforms.
>>
>> Signed-off-by: Melody Olvera <quic_molvera@quicinc.com>
>> ---
>>  Documentation/devicetree/bindings/firmware/qcom,scm.yaml | 2 ++
>>  1 file changed, 2 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/firmware/qcom,scm.yaml b/Documentation/devicetree/bindings/firmware/qcom,scm.yaml
>> index c5b76c9f7ad0..b47a5dda3c3e 100644
>> --- a/Documentation/devicetree/bindings/firmware/qcom,scm.yaml
>> +++ b/Documentation/devicetree/bindings/firmware/qcom,scm.yaml
>> @@ -51,6 +51,8 @@ properties:
>>            - qcom,scm-sm8250
>>            - qcom,scm-sm8350
>>            - qcom,scm-sm8450
>> +          - qcom,scm-qdu1000
>> +          - qcom,scm-qru1000
> Items should be ordered alphabetically.
Will fix.
>
>>            - qcom,scm-qcs404
>>        - const: qcom,scm
> Patch is incomplete. Missing changes for allOf.
Will add.
>
>>  
> Best regards,
> Krzysztof

Thanks,

Melody
Dmitry Baryshkov Oct. 3, 2022, 10:14 p.m. UTC | #2
On Tue, 4 Oct 2022 at 01:02, Melody Olvera <quic_molvera@quicinc.com> wrote:
>
>
> On 10/1/2022 4:25 AM, Krzysztof Kozlowski wrote:
> > On 01/10/2022 05:06, Melody Olvera wrote:
> >> Add compatibles for scm driver for QDU1000 and QRU1000 platforms.
> >>
> >> Signed-off-by: Melody Olvera <quic_molvera@quicinc.com>
> >> ---
> >>  Documentation/devicetree/bindings/firmware/qcom,scm.yaml | 2 ++
> >>  1 file changed, 2 insertions(+)
> >>
> >> diff --git a/Documentation/devicetree/bindings/firmware/qcom,scm.yaml b/Documentation/devicetree/bindings/firmware/qcom,scm.yaml
> >> index c5b76c9f7ad0..b47a5dda3c3e 100644
> >> --- a/Documentation/devicetree/bindings/firmware/qcom,scm.yaml
> >> +++ b/Documentation/devicetree/bindings/firmware/qcom,scm.yaml
> >> @@ -51,6 +51,8 @@ properties:
> >>            - qcom,scm-sm8250
> >>            - qcom,scm-sm8350
> >>            - qcom,scm-sm8450
> >> +          - qcom,scm-qdu1000
> >> +          - qcom,scm-qru1000

I think after seeing all the patchsets it's time to ask the following
question. Do we really need a duplicate compatibility families:
qdu1000 vs qru1000? I'd suggest using a single set of compatibile
strings in most of the cases.
Settle down onto a single name (qdu,qru, qdru, whatever) and define
distinct compat strings only when there is an actual difference?

E.g .we don't have separate compatible strings for all the sda660,
apq8096, etc. unless this is required by the corresponding hardware
block not being compatible with corresponding sdm or msm counterpart.

> > Items should be ordered alphabetically.
> Will fix.
> >
> >>            - qcom,scm-qcs404
> >>        - const: qcom,scm
> > Patch is incomplete. Missing changes for allOf.
> Will add.
> >
> >>
> > Best regards,
> > Krzysztof
>
> Thanks,
>
> Melody
>
Krzysztof Kozlowski Oct. 4, 2022, 6:53 a.m. UTC | #3
On 04/10/2022 00:14, Dmitry Baryshkov wrote:
> On Tue, 4 Oct 2022 at 01:02, Melody Olvera <quic_molvera@quicinc.com> wrote:
>>
>>
>> On 10/1/2022 4:25 AM, Krzysztof Kozlowski wrote:
>>> On 01/10/2022 05:06, Melody Olvera wrote:
>>>> Add compatibles for scm driver for QDU1000 and QRU1000 platforms.
>>>>
>>>> Signed-off-by: Melody Olvera <quic_molvera@quicinc.com>
>>>> ---
>>>>  Documentation/devicetree/bindings/firmware/qcom,scm.yaml | 2 ++
>>>>  1 file changed, 2 insertions(+)
>>>>
>>>> diff --git a/Documentation/devicetree/bindings/firmware/qcom,scm.yaml b/Documentation/devicetree/bindings/firmware/qcom,scm.yaml
>>>> index c5b76c9f7ad0..b47a5dda3c3e 100644
>>>> --- a/Documentation/devicetree/bindings/firmware/qcom,scm.yaml
>>>> +++ b/Documentation/devicetree/bindings/firmware/qcom,scm.yaml
>>>> @@ -51,6 +51,8 @@ properties:
>>>>            - qcom,scm-sm8250
>>>>            - qcom,scm-sm8350
>>>>            - qcom,scm-sm8450
>>>> +          - qcom,scm-qdu1000
>>>> +          - qcom,scm-qru1000
> 
> I think after seeing all the patchsets it's time to ask the following
> question. Do we really need a duplicate compatibility families:
> qdu1000 vs qru1000? I'd suggest using a single set of compatibile
> strings in most of the cases.
> Settle down onto a single name (qdu,qru, qdru, whatever) and define
> distinct compat strings only when there is an actual difference?
> 
> E.g .we don't have separate compatible strings for all the sda660,
> apq8096, etc. unless this is required by the corresponding hardware
> block not being compatible with corresponding sdm or msm counterpart.
> 

I am not that fluent in Qualcomm naming, so let me ask - what are the
differences between QDU and QRU?

For compatible (and/or similar) devices the general recommendation is to
have specific compatibles followed by fallback. Even if devices are
very, very, very similar, usually the recommendation still stays.

Best regards,
Krzysztof
Dmitry Baryshkov Oct. 4, 2022, 7:36 a.m. UTC | #4
On Tue, 4 Oct 2022 at 09:53, Krzysztof Kozlowski
<krzysztof.kozlowski@linaro.org> wrote:
>
> On 04/10/2022 00:14, Dmitry Baryshkov wrote:
> > On Tue, 4 Oct 2022 at 01:02, Melody Olvera <quic_molvera@quicinc.com> wrote:
> >>
> >>
> >> On 10/1/2022 4:25 AM, Krzysztof Kozlowski wrote:
> >>> On 01/10/2022 05:06, Melody Olvera wrote:
> >>>> Add compatibles for scm driver for QDU1000 and QRU1000 platforms.
> >>>>
> >>>> Signed-off-by: Melody Olvera <quic_molvera@quicinc.com>
> >>>> ---
> >>>>  Documentation/devicetree/bindings/firmware/qcom,scm.yaml | 2 ++
> >>>>  1 file changed, 2 insertions(+)
> >>>>
> >>>> diff --git a/Documentation/devicetree/bindings/firmware/qcom,scm.yaml b/Documentation/devicetree/bindings/firmware/qcom,scm.yaml
> >>>> index c5b76c9f7ad0..b47a5dda3c3e 100644
> >>>> --- a/Documentation/devicetree/bindings/firmware/qcom,scm.yaml
> >>>> +++ b/Documentation/devicetree/bindings/firmware/qcom,scm.yaml
> >>>> @@ -51,6 +51,8 @@ properties:
> >>>>            - qcom,scm-sm8250
> >>>>            - qcom,scm-sm8350
> >>>>            - qcom,scm-sm8450
> >>>> +          - qcom,scm-qdu1000
> >>>> +          - qcom,scm-qru1000
> >
> > I think after seeing all the patchsets it's time to ask the following
> > question. Do we really need a duplicate compatibility families:
> > qdu1000 vs qru1000? I'd suggest using a single set of compatibile
> > strings in most of the cases.
> > Settle down onto a single name (qdu,qru, qdru, whatever) and define
> > distinct compat strings only when there is an actual difference?
> >
> > E.g .we don't have separate compatible strings for all the sda660,
> > apq8096, etc. unless this is required by the corresponding hardware
> > block not being compatible with corresponding sdm or msm counterpart.
> >
>
> I am not that fluent in Qualcomm naming, so let me ask - what are the
> differences between QDU and QRU?
>
> For compatible (and/or similar) devices the general recommendation is to
> have specific compatibles followed by fallback. Even if devices are
> very, very, very similar, usually the recommendation still stays.

Well, true. But in some cases we handle this by using a single set of
compatibles. Consider e.g. sa8155 vs sm8150 (sa8155 overrides just few
compats that differ). Or qrb5165 vs sm8250 (there is no separate
qrb5165.dtsi). APQ8096 (#include "msm8996.dtsi"). Etc.

I'd say this really depends on the actual difference between qru and qdu.
Melody Olvera Oct. 4, 2022, 3:52 p.m. UTC | #5
On 10/4/2022 2:36 AM, Dmitry Baryshkov wrote:
> On Tue, 4 Oct 2022 at 09:53, Krzysztof Kozlowski
> <krzysztof.kozlowski@linaro.org> wrote:
>> On 04/10/2022 00:14, Dmitry Baryshkov wrote:
>>> On Tue, 4 Oct 2022 at 01:02, Melody Olvera <quic_molvera@quicinc.com> wrote:
>>>>
>>>> On 10/1/2022 4:25 AM, Krzysztof Kozlowski wrote:
>>>>> On 01/10/2022 05:06, Melody Olvera wrote:
>>>>>> Add compatibles for scm driver for QDU1000 and QRU1000 platforms.
>>>>>>
>>>>>> Signed-off-by: Melody Olvera <quic_molvera@quicinc.com>
>>>>>> ---
>>>>>>  Documentation/devicetree/bindings/firmware/qcom,scm.yaml | 2 ++
>>>>>>  1 file changed, 2 insertions(+)
>>>>>>
>>>>>> diff --git a/Documentation/devicetree/bindings/firmware/qcom,scm.yaml b/Documentation/devicetree/bindings/firmware/qcom,scm.yaml
>>>>>> index c5b76c9f7ad0..b47a5dda3c3e 100644
>>>>>> --- a/Documentation/devicetree/bindings/firmware/qcom,scm.yaml
>>>>>> +++ b/Documentation/devicetree/bindings/firmware/qcom,scm.yaml
>>>>>> @@ -51,6 +51,8 @@ properties:
>>>>>>            - qcom,scm-sm8250
>>>>>>            - qcom,scm-sm8350
>>>>>>            - qcom,scm-sm8450
>>>>>> +          - qcom,scm-qdu1000
>>>>>> +          - qcom,scm-qru1000
>>> I think after seeing all the patchsets it's time to ask the following
>>> question. Do we really need a duplicate compatibility families:
>>> qdu1000 vs qru1000? I'd suggest using a single set of compatibile
>>> strings in most of the cases.
>>> Settle down onto a single name (qdu,qru, qdru, whatever) and define
>>> distinct compat strings only when there is an actual difference?
>>>
>>> E.g .we don't have separate compatible strings for all the sda660,
>>> apq8096, etc. unless this is required by the corresponding hardware
>>> block not being compatible with corresponding sdm or msm counterpart.
>>>
>> I am not that fluent in Qualcomm naming, so let me ask - what are the
>> differences between QDU and QRU?
>>
>> For compatible (and/or similar) devices the general recommendation is to
>> have specific compatibles followed by fallback. Even if devices are
>> very, very, very similar, usually the recommendation still stays.
> Well, true. But in some cases we handle this by using a single set of
> compatibles. Consider e.g. sa8155 vs sm8150 (sa8155 overrides just few
> compats that differ). Or qrb5165 vs sm8250 (there is no separate
> qrb5165.dtsi). APQ8096 (#include "msm8996.dtsi"). Etc.
>
> I'd say this really depends on the actual difference between qru and qdu.

To add some clarification, there's pretty little functional difference between the QDU (Distributed Unit) and the QRU (Radio Unit); they're largely the same SoC from the kernel's standpoint. I wasn't sure if it made more sense to separate the compat strings or mash them together (using qdru to specify that it applies to both), so I kept separate compat strings in case there was a separate RU/DU use case down the line and also to avoid some confusion (I guess that didn't work though). It makes the most sense in my mind to just use the qdru compat string for the things that apply to both SoCs (which is most of what's submitted currently) and then we can do qdu/qru specific override strings for more specific drivers.

Thanks,

Melody
Melody Olvera Oct. 4, 2022, 4:08 p.m. UTC | #6
On 10/4/2022 10:52 AM, Melody Olvera wrote:
> On 10/4/2022 2:36 AM, Dmitry Baryshkov wrote:
>> On Tue, 4 Oct 2022 at 09:53, Krzysztof Kozlowski
>> <krzysztof.kozlowski@linaro.org> wrote:
>>> On 04/10/2022 00:14, Dmitry Baryshkov wrote:
>>>> On Tue, 4 Oct 2022 at 01:02, Melody Olvera <quic_molvera@quicinc.com> wrote:
>>>>> On 10/1/2022 4:25 AM, Krzysztof Kozlowski wrote:
>>>>>> On 01/10/2022 05:06, Melody Olvera wrote:
>>>>>>> Add compatibles for scm driver for QDU1000 and QRU1000 platforms.
>>>>>>>
>>>>>>> Signed-off-by: Melody Olvera <quic_molvera@quicinc.com>
>>>>>>> ---
>>>>>>>  Documentation/devicetree/bindings/firmware/qcom,scm.yaml | 2 ++
>>>>>>>  1 file changed, 2 insertions(+)
>>>>>>>
>>>>>>> diff --git a/Documentation/devicetree/bindings/firmware/qcom,scm.yaml b/Documentation/devicetree/bindings/firmware/qcom,scm.yaml
>>>>>>> index c5b76c9f7ad0..b47a5dda3c3e 100644
>>>>>>> --- a/Documentation/devicetree/bindings/firmware/qcom,scm.yaml
>>>>>>> +++ b/Documentation/devicetree/bindings/firmware/qcom,scm.yaml
>>>>>>> @@ -51,6 +51,8 @@ properties:
>>>>>>>            - qcom,scm-sm8250
>>>>>>>            - qcom,scm-sm8350
>>>>>>>            - qcom,scm-sm8450
>>>>>>> +          - qcom,scm-qdu1000
>>>>>>> +          - qcom,scm-qru1000
>>>> I think after seeing all the patchsets it's time to ask the following
>>>> question. Do we really need a duplicate compatibility families:
>>>> qdu1000 vs qru1000? I'd suggest using a single set of compatibile
>>>> strings in most of the cases.
>>>> Settle down onto a single name (qdu,qru, qdru, whatever) and define
>>>> distinct compat strings only when there is an actual difference?
>>>>
>>>> E.g .we don't have separate compatible strings for all the sda660,
>>>> apq8096, etc. unless this is required by the corresponding hardware
>>>> block not being compatible with corresponding sdm or msm counterpart.
>>>>
>>> I am not that fluent in Qualcomm naming, so let me ask - what are the
>>> differences between QDU and QRU?
>>>
>>> For compatible (and/or similar) devices the general recommendation is to
>>> have specific compatibles followed by fallback. Even if devices are
>>> very, very, very similar, usually the recommendation still stays.
>> Well, true. But in some cases we handle this by using a single set of
>> compatibles. Consider e.g. sa8155 vs sm8150 (sa8155 overrides just few
>> compats that differ). Or qrb5165 vs sm8250 (there is no separate
>> qrb5165.dtsi). APQ8096 (#include "msm8996.dtsi"). Etc.
>>
>> I'd say this really depends on the actual difference between qru and qdu.
> To add some clarification, there's pretty little functional
> difference between the QDU (Distributed Unit) and the QRU
> (Radio Unit); they're largely the same SoC from the kernel's
> standpoint. I wasn't sure if it made more sense to separate
> the compat strings or mash them together (using qdru to
> specify that it applies to both), so I kept separate compat
> strings in case there was a separate RU/DU use case down
> the line and also to avoid some confusion (I guess that
> didn't work though). It makes the most sense in my mind
> to just use the qdru compat string for the things that apply
> to both SoCs (which is most of what's submitted currently) and
> then we can do qdu/qru specific override strings for more
> specific drivers. 
> Thanks, Melody 
Fixed formatting.
Dmitry Baryshkov Oct. 4, 2022, 9:05 p.m. UTC | #7
On Tue, 4 Oct 2022 at 18:52, Melody Olvera <quic_molvera@quicinc.com> wrote:
>
>
> On 10/4/2022 2:36 AM, Dmitry Baryshkov wrote:
> > On Tue, 4 Oct 2022 at 09:53, Krzysztof Kozlowski
> > <krzysztof.kozlowski@linaro.org> wrote:
> >> On 04/10/2022 00:14, Dmitry Baryshkov wrote:
> >>> On Tue, 4 Oct 2022 at 01:02, Melody Olvera <quic_molvera@quicinc.com> wrote:
> >>>>
> >>>> On 10/1/2022 4:25 AM, Krzysztof Kozlowski wrote:
> >>>>> On 01/10/2022 05:06, Melody Olvera wrote:
> >>>>>> Add compatibles for scm driver for QDU1000 and QRU1000 platforms.
> >>>>>>
> >>>>>> Signed-off-by: Melody Olvera <quic_molvera@quicinc.com>
> >>>>>> ---
> >>>>>>  Documentation/devicetree/bindings/firmware/qcom,scm.yaml | 2 ++
> >>>>>>  1 file changed, 2 insertions(+)
> >>>>>>
> >>>>>> diff --git a/Documentation/devicetree/bindings/firmware/qcom,scm.yaml b/Documentation/devicetree/bindings/firmware/qcom,scm.yaml
> >>>>>> index c5b76c9f7ad0..b47a5dda3c3e 100644
> >>>>>> --- a/Documentation/devicetree/bindings/firmware/qcom,scm.yaml
> >>>>>> +++ b/Documentation/devicetree/bindings/firmware/qcom,scm.yaml
> >>>>>> @@ -51,6 +51,8 @@ properties:
> >>>>>>            - qcom,scm-sm8250
> >>>>>>            - qcom,scm-sm8350
> >>>>>>            - qcom,scm-sm8450
> >>>>>> +          - qcom,scm-qdu1000
> >>>>>> +          - qcom,scm-qru1000
> >>> I think after seeing all the patchsets it's time to ask the following
> >>> question. Do we really need a duplicate compatibility families:
> >>> qdu1000 vs qru1000? I'd suggest using a single set of compatibile
> >>> strings in most of the cases.
> >>> Settle down onto a single name (qdu,qru, qdru, whatever) and define
> >>> distinct compat strings only when there is an actual difference?
> >>>
> >>> E.g .we don't have separate compatible strings for all the sda660,
> >>> apq8096, etc. unless this is required by the corresponding hardware
> >>> block not being compatible with corresponding sdm or msm counterpart.
> >>>
> >> I am not that fluent in Qualcomm naming, so let me ask - what are the
> >> differences between QDU and QRU?
> >>
> >> For compatible (and/or similar) devices the general recommendation is to
> >> have specific compatibles followed by fallback. Even if devices are
> >> very, very, very similar, usually the recommendation still stays.
> > Well, true. But in some cases we handle this by using a single set of
> > compatibles. Consider e.g. sa8155 vs sm8150 (sa8155 overrides just few
> > compats that differ). Or qrb5165 vs sm8250 (there is no separate
> > qrb5165.dtsi). APQ8096 (#include "msm8996.dtsi"). Etc.
> >
> > I'd say this really depends on the actual difference between qru and qdu.
>
> To add some clarification, there's pretty little functional difference between the QDU (Distributed Unit) and the QRU (Radio Unit); they're largely the same SoC from the kernel's standpoint. I wasn't sure if it made more sense to separate the compat strings or mash them together (using qdru to specify that it applies to both), so I kept separate compat strings in case there was a separate RU/DU use case down the line and also to avoid some confusion (I guess that didn't work though). It makes the most sense in my mind to just use the qdru compat string for the things that apply to both SoCs (which is most of what's submitted currently) and then we can do qdu/qru specific override strings for more specific drivers.

Unless Krzysztof or Bjorn have other opinion, I'd suggest adding a
single compat string, It might be qcom,qdru1000-foo or just
qcom,qdu1000-foo (with having a separate qcom,qru1000-foo where
applicable). But the final decision is from Rob, Krzysztof and Bjorn.
Krzysztof Kozlowski Oct. 5, 2022, 8:27 a.m. UTC | #8
On 04/10/2022 23:05, Dmitry Baryshkov wrote:
> On Tue, 4 Oct 2022 at 18:52, Melody Olvera <quic_molvera@quicinc.com> wrote:
>>
>>
>> On 10/4/2022 2:36 AM, Dmitry Baryshkov wrote:
>>> On Tue, 4 Oct 2022 at 09:53, Krzysztof Kozlowski
>>> <krzysztof.kozlowski@linaro.org> wrote:
>>>> On 04/10/2022 00:14, Dmitry Baryshkov wrote:
>>>>> On Tue, 4 Oct 2022 at 01:02, Melody Olvera <quic_molvera@quicinc.com> wrote:
>>>>>>
>>>>>> On 10/1/2022 4:25 AM, Krzysztof Kozlowski wrote:
>>>>>>> On 01/10/2022 05:06, Melody Olvera wrote:
>>>>>>>> Add compatibles for scm driver for QDU1000 and QRU1000 platforms.
>>>>>>>>
>>>>>>>> Signed-off-by: Melody Olvera <quic_molvera@quicinc.com>
>>>>>>>> ---
>>>>>>>>  Documentation/devicetree/bindings/firmware/qcom,scm.yaml | 2 ++
>>>>>>>>  1 file changed, 2 insertions(+)
>>>>>>>>
>>>>>>>> diff --git a/Documentation/devicetree/bindings/firmware/qcom,scm.yaml b/Documentation/devicetree/bindings/firmware/qcom,scm.yaml
>>>>>>>> index c5b76c9f7ad0..b47a5dda3c3e 100644
>>>>>>>> --- a/Documentation/devicetree/bindings/firmware/qcom,scm.yaml
>>>>>>>> +++ b/Documentation/devicetree/bindings/firmware/qcom,scm.yaml
>>>>>>>> @@ -51,6 +51,8 @@ properties:
>>>>>>>>            - qcom,scm-sm8250
>>>>>>>>            - qcom,scm-sm8350
>>>>>>>>            - qcom,scm-sm8450
>>>>>>>> +          - qcom,scm-qdu1000
>>>>>>>> +          - qcom,scm-qru1000
>>>>> I think after seeing all the patchsets it's time to ask the following
>>>>> question. Do we really need a duplicate compatibility families:
>>>>> qdu1000 vs qru1000? I'd suggest using a single set of compatibile
>>>>> strings in most of the cases.
>>>>> Settle down onto a single name (qdu,qru, qdru, whatever) and define
>>>>> distinct compat strings only when there is an actual difference?
>>>>>
>>>>> E.g .we don't have separate compatible strings for all the sda660,
>>>>> apq8096, etc. unless this is required by the corresponding hardware
>>>>> block not being compatible with corresponding sdm or msm counterpart.
>>>>>
>>>> I am not that fluent in Qualcomm naming, so let me ask - what are the
>>>> differences between QDU and QRU?
>>>>
>>>> For compatible (and/or similar) devices the general recommendation is to
>>>> have specific compatibles followed by fallback. Even if devices are
>>>> very, very, very similar, usually the recommendation still stays.
>>> Well, true. But in some cases we handle this by using a single set of
>>> compatibles. Consider e.g. sa8155 vs sm8150 (sa8155 overrides just few
>>> compats that differ). Or qrb5165 vs sm8250 (there is no separate
>>> qrb5165.dtsi). APQ8096 (#include "msm8996.dtsi"). Etc.
>>>
>>> I'd say this really depends on the actual difference between qru and qdu.
>>
>> To add some clarification, there's pretty little functional difference between the QDU (Distributed Unit) and the QRU (Radio Unit); they're largely the same SoC from the kernel's standpoint. I wasn't sure if it made more sense to separate the compat strings or mash them together (using qdru to specify that it applies to both), so I kept separate compat strings in case there was a separate RU/DU use case down the line and also to avoid some confusion (I guess that didn't work though). It makes the most sense in my mind to just use the qdru compat string for the things that apply to both SoCs (which is most of what's submitted currently) and then we can do qdu/qru specific override strings for more specific drivers.
> 
> Unless Krzysztof or Bjorn have other opinion, I'd suggest adding a
> single compat string, It might be qcom,qdru1000-foo or just
> qcom,qdu1000-foo (with having a separate qcom,qru1000-foo where
> applicable). But the final decision is from Rob, Krzysztof and Bjorn.

If qdru1000 is a real SoC name, then it is fine. But it seems it is
rather a wildcard, which in general is discouraged. Go with qdu1000 and
optionally prepended with qru1000.

Best regards,
Krzysztof
Trilok Soni Oct. 5, 2022, 9:08 p.m. UTC | #9
On 10/5/2022 1:27 AM, Krzysztof Kozlowski wrote:
> On 04/10/2022 23:05, Dmitry Baryshkov wrote:
>> On Tue, 4 Oct 2022 at 18:52, Melody Olvera <quic_molvera@quicinc.com> wrote:
>>>
>>>
>>> On 10/4/2022 2:36 AM, Dmitry Baryshkov wrote:
>>>> On Tue, 4 Oct 2022 at 09:53, Krzysztof Kozlowski
>>>> <krzysztof.kozlowski@linaro.org> wrote:
>>>>> On 04/10/2022 00:14, Dmitry Baryshkov wrote:
>>>>>> On Tue, 4 Oct 2022 at 01:02, Melody Olvera <quic_molvera@quicinc.com> wrote:
>>>>>>>
>>>>>>> On 10/1/2022 4:25 AM, Krzysztof Kozlowski wrote:
>>>>>>>> On 01/10/2022 05:06, Melody Olvera wrote:
>>>>>>>>> Add compatibles for scm driver for QDU1000 and QRU1000 platforms.
>>>>>>>>>
>>>>>>>>> Signed-off-by: Melody Olvera <quic_molvera@quicinc.com>
>>>>>>>>> ---
>>>>>>>>>   Documentation/devicetree/bindings/firmware/qcom,scm.yaml | 2 ++
>>>>>>>>>   1 file changed, 2 insertions(+)
>>>>>>>>>
>>>>>>>>> diff --git a/Documentation/devicetree/bindings/firmware/qcom,scm.yaml b/Documentation/devicetree/bindings/firmware/qcom,scm.yaml
>>>>>>>>> index c5b76c9f7ad0..b47a5dda3c3e 100644
>>>>>>>>> --- a/Documentation/devicetree/bindings/firmware/qcom,scm.yaml
>>>>>>>>> +++ b/Documentation/devicetree/bindings/firmware/qcom,scm.yaml
>>>>>>>>> @@ -51,6 +51,8 @@ properties:
>>>>>>>>>             - qcom,scm-sm8250
>>>>>>>>>             - qcom,scm-sm8350
>>>>>>>>>             - qcom,scm-sm8450
>>>>>>>>> +          - qcom,scm-qdu1000
>>>>>>>>> +          - qcom,scm-qru1000
>>>>>> I think after seeing all the patchsets it's time to ask the following
>>>>>> question. Do we really need a duplicate compatibility families:
>>>>>> qdu1000 vs qru1000? I'd suggest using a single set of compatibile
>>>>>> strings in most of the cases.
>>>>>> Settle down onto a single name (qdu,qru, qdru, whatever) and define
>>>>>> distinct compat strings only when there is an actual difference?
>>>>>>
>>>>>> E.g .we don't have separate compatible strings for all the sda660,
>>>>>> apq8096, etc. unless this is required by the corresponding hardware
>>>>>> block not being compatible with corresponding sdm or msm counterpart.
>>>>>>
>>>>> I am not that fluent in Qualcomm naming, so let me ask - what are the
>>>>> differences between QDU and QRU?
>>>>>
>>>>> For compatible (and/or similar) devices the general recommendation is to
>>>>> have specific compatibles followed by fallback. Even if devices are
>>>>> very, very, very similar, usually the recommendation still stays.
>>>> Well, true. But in some cases we handle this by using a single set of
>>>> compatibles. Consider e.g. sa8155 vs sm8150 (sa8155 overrides just few
>>>> compats that differ). Or qrb5165 vs sm8250 (there is no separate
>>>> qrb5165.dtsi). APQ8096 (#include "msm8996.dtsi"). Etc.
>>>>
>>>> I'd say this really depends on the actual difference between qru and qdu.
>>>
>>> To add some clarification, there's pretty little functional difference between the QDU (Distributed Unit) and the QRU (Radio Unit); they're largely the same SoC from the kernel's standpoint. I wasn't sure if it made more sense to separate the compat strings or mash them together (using qdru to specify that it applies to both), so I kept separate compat strings in case there was a separate RU/DU use case down the line and also to avoid some confusion (I guess that didn't work though). It makes the most sense in my mind to just use the qdru compat string for the things that apply to both SoCs (which is most of what's submitted currently) and then we can do qdu/qru specific override strings for more specific drivers.
>>
>> Unless Krzysztof or Bjorn have other opinion, I'd suggest adding a
>> single compat string, It might be qcom,qdru1000-foo or just
>> qcom,qdu1000-foo (with having a separate qcom,qru1000-foo where
>> applicable). But the final decision is from Rob, Krzysztof and Bjorn.
> 
> If qdru1000 is a real SoC name, then it is fine. But it seems it is
> rather a wildcard, which in general is discouraged. Go with qdu1000 and
> optionally prepended with qru1000.

qdru1000 is not a real SOC, so let's not use that. Prefer to use qdu1000 
and qru1000 with whatever approach we decide.

---Trilok Soni
diff mbox series

Patch

diff --git a/Documentation/devicetree/bindings/firmware/qcom,scm.yaml b/Documentation/devicetree/bindings/firmware/qcom,scm.yaml
index c5b76c9f7ad0..b47a5dda3c3e 100644
--- a/Documentation/devicetree/bindings/firmware/qcom,scm.yaml
+++ b/Documentation/devicetree/bindings/firmware/qcom,scm.yaml
@@ -51,6 +51,8 @@  properties:
           - qcom,scm-sm8250
           - qcom,scm-sm8350
           - qcom,scm-sm8450
+          - qcom,scm-qdu1000
+          - qcom,scm-qru1000
           - qcom,scm-qcs404
       - const: qcom,scm