[PATCH 0/2] dt-bindings: arm: cpus: Fix and extend Qualcomm Oryon compatibles

[PATCH 0/2] dt-bindings: arm: cpus: Fix and extend Qualcomm Oryon compatibles

[Shawn Guo]

This series restores compatible qcom,oryon-1-4 which was accidentally
dropped by merge commit f6935ae6147b, and then adds qcom,oryon-1-5 which
is found on Nord SoC.

Shawn Guo (2):
  dt-bindings: arm: cpus: Restore qcom,oryon-1-4 compatible
  dt-bindings: arm: cpus: Add compatible qcom,oryon-1-5

 Documentation/devicetree/bindings/arm/cpus.yaml | 2 ++
 1 file changed, 2 insertions(+)

-- 
2.43.0

[PATCH 1/2] dt-bindings: arm: cpus: Restore qcom,oryon-1-4 compatible

[Shawn Guo]

It seems that compatible qcom,oryon-1-4 was accidentally dropped during
the conflict resolution in commit f6935ae6147b ("Merge branch 'for-next'
of https://git.kernel.org/pub/scm/linux/kernel/git/robh/linux.git").
Restore it.

Signed-off-by: Shawn Guo <shengchao.guo@oss.qualcomm.com>
---
 Documentation/devicetree/bindings/arm/cpus.yaml | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/arm/cpus.yaml b/Documentation/devicetree/bindings/arm/cpus.yaml
index 471902ddbb65..5f5ff5e51e51 100644
--- a/Documentation/devicetree/bindings/arm/cpus.yaml
+++ b/Documentation/devicetree/bindings/arm/cpus.yaml
@@ -222,6 +222,7 @@ properties:
           - qcom,oryon-1-1
           - qcom,oryon-1-2
           - qcom,oryon-1-3
+          - qcom,oryon-1-4
           - qcom,oryon-2-1
           - qcom,oryon-2-2
           - qcom,oryon-2-3
-- 
2.43.0

[PATCH 2/2] dt-bindings: arm: cpus: Add compatible qcom,oryon-1-5

[Shawn Guo]

Qualcomm Oryon 1-5 is found on Nord SoC.  Add compatible for it.

  $ cat /proc/cpuinfo
  ...
  CPU implementer : 0x51
  CPU architecture: 8
  CPU variant     : 0x5
  CPU part        : 0x001
  CPU revision    : 4

Signed-off-by: Shawn Guo <shengchao.guo@oss.qualcomm.com>
---
 Documentation/devicetree/bindings/arm/cpus.yaml | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/arm/cpus.yaml b/Documentation/devicetree/bindings/arm/cpus.yaml
index 5f5ff5e51e51..5be89c584026 100644
--- a/Documentation/devicetree/bindings/arm/cpus.yaml
+++ b/Documentation/devicetree/bindings/arm/cpus.yaml
@@ -223,6 +223,7 @@ properties:
           - qcom,oryon-1-2
           - qcom,oryon-1-3
           - qcom,oryon-1-4
+          - qcom,oryon-1-5
           - qcom,oryon-2-1
           - qcom,oryon-2-2
           - qcom,oryon-2-3
-- 
2.43.0

Re: [PATCH 1/2] dt-bindings: arm: cpus: Restore qcom,oryon-1-4 compatible

[Konrad Dybcio]

On 4/13/26 11:16 AM, Shawn Guo wrote:
> It seems that compatible qcom,oryon-1-4 was accidentally dropped during
> the conflict resolution in commit f6935ae6147b ("Merge branch 'for-next'
> of https://git.kernel.org/pub/scm/linux/kernel/git/robh/linux.git").
> Restore it.
> 
> Signed-off-by: Shawn Guo <shengchao.guo@oss.qualcomm.com>
> ---

Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>

Konrad

Re: [PATCH 2/2] dt-bindings: arm: cpus: Add compatible qcom,oryon-1-5

[Konrad Dybcio]

On 4/13/26 11:16 AM, Shawn Guo wrote:
> Qualcomm Oryon 1-5 is found on Nord SoC.  Add compatible for it.
> 
>   $ cat /proc/cpuinfo
>   ...
>   CPU implementer : 0x51
>   CPU architecture: 8
>   CPU variant     : 0x5
>   CPU part        : 0x001
>   CPU revision    : 4
> 
> Signed-off-by: Shawn Guo <shengchao.guo@oss.qualcomm.com>
> ---

Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>

Konrad

Re: [PATCH 1/2] dt-bindings: arm: cpus: Restore qcom,oryon-1-4 compatible

[Krzysztof Kozlowski]

On 13/04/2026 11:16, Shawn Guo wrote:
> It seems that compatible qcom,oryon-1-4 was accidentally dropped during
> the conflict resolution in commit f6935ae6147b ("Merge branch 'for-next'

Don't reference commits which will never make to Linux kernel.

> of https://git.kernel.org/pub/scm/linux/kernel/git/robh/linux.git").
> Restore it.
> 
> Signed-off-by: Shawn Guo <shengchao.guo@oss.qualcomm.com>

Well, I said that merge will be difficult but Mark was sure merge is
trivial, so here we are.

Anyway, this cannot be applied. How do you exactly see it? Which tree?
Try yourself...

> ---
>  Documentation/devicetree/bindings/arm/cpus.yaml | 1 +
>  1 file changed, 1 insertion(+)


Best regards,
Krzysztof

Re: [PATCH 2/2] dt-bindings: arm: cpus: Add compatible qcom,oryon-1-5

[Krzysztof Kozlowski]

On 13/04/2026 11:16, Shawn Guo wrote:
> Qualcomm Oryon 1-5 is found on Nord SoC.  Add compatible for it.
> 
>   $ cat /proc/cpuinfo
>   ...
>   CPU implementer : 0x51
>   CPU architecture: 8
>   CPU variant     : 0x5
>   CPU part        : 0x001
>   CPU revision    : 4
> 
> Signed-off-by: Shawn Guo <shengchao.guo@oss.qualcomm.com>
> ---
>  Documentation/devicetree/bindings/arm/cpus.yaml | 1 +
>  1 file changed, 1 insertion(+)

No. I said many times. Bindings come with the user. We don't care what
is in cpuinfo of some non-upstream board (and lack of user means it is
non-upstream currently).

Please organize your patchset correctly.

Best regards,
Krzysztof

Re: [PATCH 1/2] dt-bindings: arm: cpus: Restore qcom,oryon-1-4 compatible

[Shawn Guo]

+ Mark

On Mon, Apr 13, 2026 at 12:01:06PM +0200, Krzysztof Kozlowski wrote:
> On 13/04/2026 11:16, Shawn Guo wrote:
> > It seems that compatible qcom,oryon-1-4 was accidentally dropped during
> > the conflict resolution in commit f6935ae6147b ("Merge branch 'for-next'
> 
> Don't reference commits which will never make to Linux kernel.
> 
> > of https://git.kernel.org/pub/scm/linux/kernel/git/robh/linux.git").
> > Restore it.
> > 
> > Signed-off-by: Shawn Guo <shengchao.guo@oss.qualcomm.com>
> 
> Well, I said that merge will be difficult but Mark was sure merge is
> trivial, so here we are.
> 
> Anyway, this cannot be applied. How do you exactly see it? Which tree?
> Try yourself...

Ah, right!  This can be applied nowhere, as it only fixes Mark's merge
commit on linux-next instead of mainline.

Mark,

I should have copied you from the beginning, but could you take
the patch [1] as a bug report and get linux-next fixed?

Shawn

[1] https://lore.kernel.org/all/20260413091625.607976-2-shengchao.guo@oss.qualcomm.com/

Re: [PATCH 2/2] dt-bindings: arm: cpus: Add compatible qcom,oryon-1-5

[Shawn Guo]

On Mon, Apr 13, 2026 at 12:02:48PM +0200, Krzysztof Kozlowski wrote:
> On 13/04/2026 11:16, Shawn Guo wrote:
> > Qualcomm Oryon 1-5 is found on Nord SoC.  Add compatible for it.
> > 
> >   $ cat /proc/cpuinfo
> >   ...
> >   CPU implementer : 0x51
> >   CPU architecture: 8
> >   CPU variant     : 0x5
> >   CPU part        : 0x001
> >   CPU revision    : 4
> > 
> > Signed-off-by: Shawn Guo <shengchao.guo@oss.qualcomm.com>
> > ---
> >  Documentation/devicetree/bindings/arm/cpus.yaml | 1 +
> >  1 file changed, 1 insertion(+)
> 
> No. I said many times. Bindings come with the user. We don't care what
> is in cpuinfo of some non-upstream board (and lack of user means it is
> non-upstream currently).

I was not aware of this requirement, and I see many bindings that
currently do not have any in-tree users, e.g. qcom,oryon-2-3 in cpus.yaml.

> Please organize your patchset correctly.

Are you asking for a big series that consists of all the new bindings
used by Nord DTS and DTS itself?  Unless this big series gets applied as
one-go, there are still chances that bindings get into a kernel release
without any users, e.g. subsystem maintainers pick up bindgins being
reviewed, but DTS requires more iterations and thus misses the release.

Shawn

Re: [PATCH 2/2] dt-bindings: arm: cpus: Add compatible qcom,oryon-1-5

[Krzysztof Kozlowski]

On 13/04/2026 14:36, Shawn Guo wrote:
> On Mon, Apr 13, 2026 at 12:02:48PM +0200, Krzysztof Kozlowski wrote:
>> On 13/04/2026 11:16, Shawn Guo wrote:
>>> Qualcomm Oryon 1-5 is found on Nord SoC.  Add compatible for it.
>>>
>>>   $ cat /proc/cpuinfo
>>>   ...
>>>   CPU implementer : 0x51
>>>   CPU architecture: 8
>>>   CPU variant     : 0x5
>>>   CPU part        : 0x001
>>>   CPU revision    : 4
>>>
>>> Signed-off-by: Shawn Guo <shengchao.guo@oss.qualcomm.com>
>>> ---
>>>  Documentation/devicetree/bindings/arm/cpus.yaml | 1 +
>>>  1 file changed, 1 insertion(+)
>>
>> No. I said many times. Bindings come with the user. We don't care what
>> is in cpuinfo of some non-upstream board (and lack of user means it is
>> non-upstream currently).
> 
> I was not aware of this requirement, and I see many bindings that

I am not saying anything new here.

> currently do not have any in-tree users, e.g. qcom,oryon-2-3 in cpus.yaml.

And what is the reason for having oryon-2-3 in the kernel? I treat
arguments "I found a code like this, so I can do the same" as proof of
lack of actual technical arguments.

> 
>> Please organize your patchset correctly.
> 
> Are you asking for a big series that consists of all the new bindings
> used by Nord DTS and DTS itself?  Unless this big series gets applied as
> one-go, there are still chances that bindings get into a kernel release
> without any users, e.g. subsystem maintainers pick up bindgins being
> reviewed, but DTS requires more iterations and thus misses the release.

Please follow existing rules, communicated multiple times on the mailing
list. Qualcomm also has internal guideline clarifying this.

Below are some upstream discussion clarifying this:
https://lore.kernel.org/linux-samsung-soc/CADrjBPq_0nUYRABKpskRF_dhHu+4K=duPVZX==0pr+cjSL_caQ@mail.gmail.com/T/#m2d9130a1342ab201ab49670fa6c858ee3724c83c
https://lore.kernel.org/all/49258645-d4d8-44a5-a4fc-b403c926a5d1@kernel.org/

And how to do it:
https://lore.kernel.org/all/20231121-topic-sm8650-upstream-dt-v3-0-db9d0507ffd3@linaro.org/

Best regards,
Krzysztof

Re: [PATCH 2/2] dt-bindings: arm: cpus: Add compatible qcom,oryon-1-5

[Shawn Guo]

On Mon, Apr 13, 2026 at 02:40:18PM +0200, Krzysztof Kozlowski wrote:
> >> Please organize your patchset correctly.
> > 
> > Are you asking for a big series that consists of all the new bindings
> > used by Nord DTS and DTS itself?  Unless this big series gets applied as
> > one-go, there are still chances that bindings get into a kernel release
> > without any users, e.g. subsystem maintainers pick up bindgins being
> > reviewed, but DTS requires more iterations and thus misses the release.
> 
> Please follow existing rules, communicated multiple times on the mailing
> list. Qualcomm also has internal guideline clarifying this.
> 
> Below are some upstream discussion clarifying this:
> https://lore.kernel.org/linux-samsung-soc/CADrjBPq_0nUYRABKpskRF_dhHu+4K=duPVZX==0pr+cjSL_caQ@mail.gmail.com/T/#m2d9130a1342ab201ab49670fa6c858ee3724c83c
> https://lore.kernel.org/all/49258645-d4d8-44a5-a4fc-b403c926a5d1@kernel.org/
> 
> And how to do it:
> https://lore.kernel.org/all/20231121-topic-sm8650-upstream-dt-v3-0-db9d0507ffd3@linaro.org/

That's what I'm trying to do, posting bindings in prior to DTS, so that
when posting DTS, either bindings is already merged or we can refer to
lore link of bindings.

I still need to understand you comment "Bindings come with the user".
Are you saying that bindings and DTS in different series should be posted
at the same time to show bindings has an user?

Shawn

Re: [PATCH 2/2] dt-bindings: arm: cpus: Add compatible qcom,oryon-1-5

[Krzysztof Kozlowski]

On 13/04/2026 15:10, Shawn Guo wrote:
> On Mon, Apr 13, 2026 at 02:40:18PM +0200, Krzysztof Kozlowski wrote:
>>>> Please organize your patchset correctly.
>>>
>>> Are you asking for a big series that consists of all the new bindings
>>> used by Nord DTS and DTS itself?  Unless this big series gets applied as
>>> one-go, there are still chances that bindings get into a kernel release
>>> without any users, e.g. subsystem maintainers pick up bindgins being
>>> reviewed, but DTS requires more iterations and thus misses the release.
>>
>> Please follow existing rules, communicated multiple times on the mailing
>> list. Qualcomm also has internal guideline clarifying this.
>>
>> Below are some upstream discussion clarifying this:
>> https://lore.kernel.org/linux-samsung-soc/CADrjBPq_0nUYRABKpskRF_dhHu+4K=duPVZX==0pr+cjSL_caQ@mail.gmail.com/T/#m2d9130a1342ab201ab49670fa6c858ee3724c83c
>> https://lore.kernel.org/all/49258645-d4d8-44a5-a4fc-b403c926a5d1@kernel.org/
>>
>> And how to do it:
>> https://lore.kernel.org/all/20231121-topic-sm8650-upstream-dt-v3-0-db9d0507ffd3@linaro.org/
> 
> That's what I'm trying to do, posting bindings in prior to DTS, so that

Hm? Nothing above claimed that. I am sorry, but which rule either
communicated publicly or privately encouraged or even allowed that?

> when posting DTS, either bindings is already merged or we can refer to
> lore link of bindings.
> 
> I still need to understand you comment "Bindings come with the user".
> Are you saying that bindings and DTS in different series should be posted
> at the same time to show bindings has an user?

I am saying that you cannot post bindings alone where there is no user.
Why do want even such binding? I see no point in having it in the
kernel, unless you speak about very specific exception, but then please
clarify that exception and why it applies to this work.

Best regards,
Krzysztof

Re: [PATCH 2/2] dt-bindings: arm: cpus: Add compatible qcom,oryon-1-5

[Shawn Guo]

On Mon, Apr 13, 2026 at 03:30:28PM +0200, Krzysztof Kozlowski wrote:
> On 13/04/2026 15:10, Shawn Guo wrote:
> > On Mon, Apr 13, 2026 at 02:40:18PM +0200, Krzysztof Kozlowski wrote:
> >>>> Please organize your patchset correctly.
> >>>
> >>> Are you asking for a big series that consists of all the new bindings
> >>> used by Nord DTS and DTS itself?  Unless this big series gets applied as
> >>> one-go, there are still chances that bindings get into a kernel release
> >>> without any users, e.g. subsystem maintainers pick up bindgins being
> >>> reviewed, but DTS requires more iterations and thus misses the release.
> >>
> >> Please follow existing rules, communicated multiple times on the mailing
> >> list. Qualcomm also has internal guideline clarifying this.
> >>
> >> Below are some upstream discussion clarifying this:
> >> https://lore.kernel.org/linux-samsung-soc/CADrjBPq_0nUYRABKpskRF_dhHu+4K=duPVZX==0pr+cjSL_caQ@mail.gmail.com/T/#m2d9130a1342ab201ab49670fa6c858ee3724c83c
> >> https://lore.kernel.org/all/49258645-d4d8-44a5-a4fc-b403c926a5d1@kernel.org/
> >>
> >> And how to do it:
> >> https://lore.kernel.org/all/20231121-topic-sm8650-upstream-dt-v3-0-db9d0507ffd3@linaro.org/
> > 
> > That's what I'm trying to do, posting bindings in prior to DTS, so that
> 
> Hm? Nothing above claimed that. I am sorry, but which rule either
> communicated publicly or privately encouraged or even allowed that?
> 
> > when posting DTS, either bindings is already merged or we can refer to
> > lore link of bindings.
> > 
> > I still need to understand you comment "Bindings come with the user".
> > Are you saying that bindings and DTS in different series should be posted
> > at the same time to show bindings has an user?
> 
> I am saying that you cannot post bindings alone where there is no user.
> Why do want even such binding? I see no point in having it in the
> kernel, unless you speak about very specific exception, but then please
> clarify that exception and why it applies to this work.

I think I'm getting what the requirement is now, but still not sure what
the point of the requirement is.

- Posting bindings and DTS at the same time doesn't guarantee they get
  into the same release.  It can often happen that bindings are merged
  alone into a release.  So it doesn't really help to avoid situation of
  there is bindings in-tree with no users.

- From what I can see, there are always DTS patches coming after bindings
  changes, sooner or later.  No one would be bothered to submit a bindings
  if the DTS using the bindings is only kept out of tree.

In short, there will be Nord DTS using the binding coming, and I do not
think posting them at the same time should be a requirement.

Shawn

Re: [PATCH 2/2] dt-bindings: arm: cpus: Add compatible qcom,oryon-1-5

[Krzysztof Kozlowski]

On 13/04/2026 16:34, Shawn Guo wrote:
> On Mon, Apr 13, 2026 at 03:30:28PM +0200, Krzysztof Kozlowski wrote:
>> On 13/04/2026 15:10, Shawn Guo wrote:
>>> On Mon, Apr 13, 2026 at 02:40:18PM +0200, Krzysztof Kozlowski wrote:
>>>>>> Please organize your patchset correctly.
>>>>>
>>>>> Are you asking for a big series that consists of all the new bindings
>>>>> used by Nord DTS and DTS itself?  Unless this big series gets applied as
>>>>> one-go, there are still chances that bindings get into a kernel release
>>>>> without any users, e.g. subsystem maintainers pick up bindgins being
>>>>> reviewed, but DTS requires more iterations and thus misses the release.
>>>>
>>>> Please follow existing rules, communicated multiple times on the mailing
>>>> list. Qualcomm also has internal guideline clarifying this.
>>>>
>>>> Below are some upstream discussion clarifying this:
>>>> https://lore.kernel.org/linux-samsung-soc/CADrjBPq_0nUYRABKpskRF_dhHu+4K=duPVZX==0pr+cjSL_caQ@mail.gmail.com/T/#m2d9130a1342ab201ab49670fa6c858ee3724c83c
>>>> https://lore.kernel.org/all/49258645-d4d8-44a5-a4fc-b403c926a5d1@kernel.org/
>>>>
>>>> And how to do it:
>>>> https://lore.kernel.org/all/20231121-topic-sm8650-upstream-dt-v3-0-db9d0507ffd3@linaro.org/
>>>
>>> That's what I'm trying to do, posting bindings in prior to DTS, so that
>>
>> Hm? Nothing above claimed that. I am sorry, but which rule either
>> communicated publicly or privately encouraged or even allowed that?
>>
>>> when posting DTS, either bindings is already merged or we can refer to
>>> lore link of bindings.
>>>
>>> I still need to understand you comment "Bindings come with the user".
>>> Are you saying that bindings and DTS in different series should be posted
>>> at the same time to show bindings has an user?
>>
>> I am saying that you cannot post bindings alone where there is no user.
>> Why do want even such binding? I see no point in having it in the
>> kernel, unless you speak about very specific exception, but then please
>> clarify that exception and why it applies to this work.
> 
> I think I'm getting what the requirement is now, but still not sure what
> the point of the requirement is.
> 
> - Posting bindings and DTS at the same time doesn't guarantee they get
>   into the same release.  It can often happen that bindings are merged

No one claimed it will guarantee that and no one even suggested that.
Submitting patches even describes this...

>   alone into a release.  So it doesn't really help to avoid situation of
>   there is bindings in-tree with no users.

That was not the comment from me, either. When I say there is no user, I
mean no user at all. Nowhere in ecosystem considered usptream, including
mailing list.

> 
> - From what I can see, there are always DTS patches coming after bindings
>   changes, sooner or later.  No one would be bothered to submit a bindings
>   if the DTS using the bindings is only kept out of tree.

I would be bothered. I don't want to maintain unused (unused as in
upstream) ABI. I don't care about such ABI for downstream users and no
one in upstream should spend any precious cycles on reviewing something
which serves no upstream purposes.

> 
> In short, there will be Nord DTS using the binding coming, and I do not

Maybe there will, maybe there will not.

> think posting them at the same time should be a requirement.

Well, it is a requirement as I explained previously, said that
*multiple* times on the mailing list, documented expectations in
mentioned/linked email threads. It's also documented in submitting
patches in DT (although not with that strong wording).

Best regards,
Krzysztof

Re: [PATCH 2/2] dt-bindings: arm: cpus: Add compatible qcom,oryon-1-5

[Shawn Guo]

On Mon, Apr 13, 2026 at 06:08:49PM +0200, Krzysztof Kozlowski wrote:
> On 13/04/2026 16:34, Shawn Guo wrote:
> > In short, there will be Nord DTS using the binding coming, and I do not
> 
> Maybe there will, maybe there will not.
> 
> > think posting them at the same time should be a requirement.
> 
> Well, it is a requirement as I explained previously, said that
> *multiple* times on the mailing list, documented expectations in
> mentioned/linked email threads.

To be honest, I can only read the following from mentioned email
threads.

 - Binding and DTS should be organized in separate series per subsystem
 - DTS should reference binding series by a lore link

These are what I'm trying to do, and I'm not just posting DTS
simultaneously.  I do not really read the requirement of posting
binding and DTS using it simultaneously from the email threads.

Taking a step back, even if the requirement is mentioned in an email
thread like this one, I'm not sure it's the correct or well received
way to define a requirement.  And that might be why you had to keep
repeating yourself.

> It's also documented in submitting
> patches in DT (although not with that strong wording).

Either I'm blind or reading the wrong document.  I failed to find
the requirement of posting binding and DTS using it simultaneously
in Documentation/devicetree/bindings/submitting-patches.rst.  Could you
point it out explicitly?

Shawn

Re: [PATCH 2/2] dt-bindings: arm: cpus: Add compatible qcom,oryon-1-5

[Krzysztof Kozlowski]

On 14/04/2026 03:21, Shawn Guo wrote:
> On Mon, Apr 13, 2026 at 06:08:49PM +0200, Krzysztof Kozlowski wrote:
>> On 13/04/2026 16:34, Shawn Guo wrote:
>>> In short, there will be Nord DTS using the binding coming, and I do not
>>
>> Maybe there will, maybe there will not.
>>
>>> think posting them at the same time should be a requirement.
>>
>> Well, it is a requirement as I explained previously, said that
>> *multiple* times on the mailing list, documented expectations in
>> mentioned/linked email threads.
> 
> To be honest, I can only read the following from mentioned email
> threads.
> 
>  - Binding and DTS should be organized in separate series per subsystem
>  - DTS should reference binding series by a lore link
> 
> 

The links told explicitly to organize series per subsystem/maintainer.
Who is the subsystem here?

These are what I'm trying to do, and I'm not just posting DTS
> simultaneously.  I do not really read the requirement of posting
> binding and DTS using it simultaneously from the email threads.
> 
> Taking a step back, even if the requirement is mentioned in an email
> thread like this one, I'm not sure it's the correct or well received
> way to define a requirement.  And that might be why you had to keep
> repeating yourself.
> 
>> It's also documented in submitting
>> patches in DT (although not with that strong wording).
> 
> Either I'm blind or reading the wrong document.  I failed to find
> the requirement of posting binding and DTS using it simultaneously
> in Documentation/devicetree/bindings/submitting-patches.rst.  Could you
> point it out explicitly?

Rule 8.

Best regards,
Krzysztof

Re: [PATCH 2/2] dt-bindings: arm: cpus: Add compatible qcom,oryon-1-5

[Shawn Guo]

On Tue, Apr 14, 2026 at 08:23:12AM +0200, Krzysztof Kozlowski wrote:
> On 14/04/2026 03:21, Shawn Guo wrote:
> > On Mon, Apr 13, 2026 at 06:08:49PM +0200, Krzysztof Kozlowski wrote:
> >> On 13/04/2026 16:34, Shawn Guo wrote:
> >>> In short, there will be Nord DTS using the binding coming, and I do not
> >>
> >> Maybe there will, maybe there will not.
> >>
> >>> think posting them at the same time should be a requirement.
> >>
> >> Well, it is a requirement as I explained previously, said that
> >> *multiple* times on the mailing list, documented expectations in
> >> mentioned/linked email threads.
> > 
> > To be honest, I can only read the following from mentioned email
> > threads.
> > 
> >  - Binding and DTS should be organized in separate series per subsystem
> >  - DTS should reference binding series by a lore link
> > 
> 
> The links told explicitly to organize series per subsystem/maintainer.
> Who is the subsystem here?

Rob Herring <robh@kernel.org> appears at the top of get_maintainer.pl
output, so I guess it's DT/Rob?

> > These are what I'm trying to do, and I'm not just posting DTS
> > simultaneously.  I do not really read the requirement of posting
> > binding and DTS using it simultaneously from the email threads.
> > 
> > Taking a step back, even if the requirement is mentioned in an email
> > thread like this one, I'm not sure it's the correct or well received
> > way to define a requirement.  And that might be why you had to keep
> > repeating yourself.
> > 
> >> It's also documented in submitting
> >> patches in DT (although not with that strong wording).
> > 
> > Either I'm blind or reading the wrong document.  I failed to find
> > the requirement of posting binding and DTS using it simultaneously
> > in Documentation/devicetree/bindings/submitting-patches.rst.  Could you
> > point it out explicitly?
> 
> Rule 8.

This one?

  8) If a documented compatible string is not yet matched by the
     driver, the documentation should also include a compatible
     string that is matched by the driver

Are we looking at the same version of the document?  How does that map
to the requirement of posting binding and DTS using it simultaneously we
are debating here?  I'm confused.

Shawn

Re: [PATCH 2/2] dt-bindings: arm: cpus: Add compatible qcom,oryon-1-5

[Krzysztof Kozlowski]

On 14/04/2026 08:59, Shawn Guo wrote:
> On Tue, Apr 14, 2026 at 08:23:12AM +0200, Krzysztof Kozlowski wrote:
>> On 14/04/2026 03:21, Shawn Guo wrote:
>>> On Mon, Apr 13, 2026 at 06:08:49PM +0200, Krzysztof Kozlowski wrote:
>>>> On 13/04/2026 16:34, Shawn Guo wrote:
>>>>> In short, there will be Nord DTS using the binding coming, and I do not
>>>>
>>>> Maybe there will, maybe there will not.
>>>>
>>>>> think posting them at the same time should be a requirement.
>>>>
>>>> Well, it is a requirement as I explained previously, said that
>>>> *multiple* times on the mailing list, documented expectations in
>>>> mentioned/linked email threads.
>>>
>>> To be honest, I can only read the following from mentioned email
>>> threads.
>>>
>>>  - Binding and DTS should be organized in separate series per subsystem
>>>  - DTS should reference binding series by a lore link
>>>
>>
>> The links told explicitly to organize series per subsystem/maintainer.
>> Who is the subsystem here?
> 
> Rob Herring <robh@kernel.org> appears at the top of get_maintainer.pl
> output, so I guess it's DT/Rob?
> 
>>> These are what I'm trying to do, and I'm not just posting DTS
>>> simultaneously.  I do not really read the requirement of posting
>>> binding and DTS using it simultaneously from the email threads.
>>>
>>> Taking a step back, even if the requirement is mentioned in an email
>>> thread like this one, I'm not sure it's the correct or well received
>>> way to define a requirement.  And that might be why you had to keep
>>> repeating yourself.
>>>
>>>> It's also documented in submitting
>>>> patches in DT (although not with that strong wording).
>>>
>>> Either I'm blind or reading the wrong document.  I failed to find
>>> the requirement of posting binding and DTS using it simultaneously
>>> in Documentation/devicetree/bindings/submitting-patches.rst.  Could you
>>> point it out explicitly?
>>
>> Rule 8.
> 
> This one?
> 
>   8) If a documented compatible string is not yet matched by the
>      driver, the documentation should also include a compatible
>      string that is matched by the driver
> 
> Are we looking at the same version of the document?  How does that map
> to the requirement of posting binding and DTS using it simultaneously we
> are debating here?  I'm confused.

Why is the rule there and what is expressed by it? We do not discuss
posting binding and DTS using simultaneously. We discuss lack of user of
a binding.

I even asked earlier explicitly:

"Why do want even such binding?"

Do you have a user of this compatible? Not a single one. So apply the
spirit of that rule. Or if you cannot get the spirit, you could apply it
literally.

Best regards,
Krzysztof

Re: [PATCH 2/2] dt-bindings: arm: cpus: Add compatible qcom,oryon-1-5

[Krzysztof Kozlowski]

On 14/04/2026 08:59, Shawn Guo wrote:
> On Tue, Apr 14, 2026 at 08:23:12AM +0200, Krzysztof Kozlowski wrote:
>> On 14/04/2026 03:21, Shawn Guo wrote:
>>> On Mon, Apr 13, 2026 at 06:08:49PM +0200, Krzysztof Kozlowski wrote:
>>>> On 13/04/2026 16:34, Shawn Guo wrote:
>>>>> In short, there will be Nord DTS using the binding coming, and I do not
>>>>
>>>> Maybe there will, maybe there will not.
>>>>
>>>>> think posting them at the same time should be a requirement.
>>>>
>>>> Well, it is a requirement as I explained previously, said that
>>>> *multiple* times on the mailing list, documented expectations in
>>>> mentioned/linked email threads.
>>>
>>> To be honest, I can only read the following from mentioned email
>>> threads.
>>>
>>>  - Binding and DTS should be organized in separate series per subsystem
>>>  - DTS should reference binding series by a lore link
>>>
>>
>> The links told explicitly to organize series per subsystem/maintainer.
>> Who is the subsystem here?
> 
> Rob Herring <robh@kernel.org> appears at the top of get_maintainer.pl
> output, so I guess it's DT/Rob?

If you guess, then why did you post it separately from the other patches
targeting Rob?

But you mentioned oryon-2-3 compatible. Who applied it? Rob? Who applied
Kryo? Or Samsung Mongoose?

I explained you the rule - bindings go with the subsystem and you post
everything targeting subsystem in one patchset. This was explicitly
asked for in my referenced postings. The SoC is the primary subsystem here.

Best regards,
Krzysztof

Re: [PATCH 2/2] dt-bindings: arm: cpus: Add compatible qcom,oryon-1-5

[Shawn Guo]

On Tue, Apr 14, 2026 at 09:11:38AM +0200, Krzysztof Kozlowski wrote:
> On 14/04/2026 08:59, Shawn Guo wrote:
> > On Tue, Apr 14, 2026 at 08:23:12AM +0200, Krzysztof Kozlowski wrote:
> >> On 14/04/2026 03:21, Shawn Guo wrote:
> >>> On Mon, Apr 13, 2026 at 06:08:49PM +0200, Krzysztof Kozlowski wrote:
> >>>> On 13/04/2026 16:34, Shawn Guo wrote:
> >>>>> In short, there will be Nord DTS using the binding coming, and I do not
> >>>>
> >>>> Maybe there will, maybe there will not.
> >>>>
> >>>>> think posting them at the same time should be a requirement.
> >>>>
> >>>> Well, it is a requirement as I explained previously, said that
> >>>> *multiple* times on the mailing list, documented expectations in
> >>>> mentioned/linked email threads.
> >>>
> >>> To be honest, I can only read the following from mentioned email
> >>> threads.
> >>>
> >>>  - Binding and DTS should be organized in separate series per subsystem
> >>>  - DTS should reference binding series by a lore link
> >>>
> >>
> >> The links told explicitly to organize series per subsystem/maintainer.
> >> Who is the subsystem here?
> > 
> > Rob Herring <robh@kernel.org> appears at the top of get_maintainer.pl
> > output, so I guess it's DT/Rob?
> 
> If you guess, then why did you post it separately from the other patches
> targeting Rob?

I should have done that.

> But you mentioned oryon-2-3 compatible. Who applied it? Rob? Who applied
> Kryo? Or Samsung Mongoose?

I was misled by commit 96e71f817b02 ("dt-bindings: arm: cpus: Extend
Qualcomm Oryon compatibles"), which should also been applied by DT/Rob,
IMO.  The merge conflict where oryon-1-4 got lost could have been avoided
if the commit above went through DT tree, since your commit 0220405d7e09
("dt-bindings: arm: cpus: Deprecate Qualcomm generic compatibles") already
went to DT.

> I explained you the rule - bindings go with the subsystem and you post
> everything targeting subsystem in one patchset. This was explicitly
> asked for in my referenced postings.

Being a platform maintainer for 1.5 decades, I knew this pretty well.

> The SoC is the primary subsystem here.

The same binding switching its belonging subsystem is a new thing to me.

Shawn