From: Aaron Kling <webgeek1234@gmail.com>

Namely:
* Odin 2
* Odin 2 Mini
* Odin 2 Portal
* Thor

Signed-off-by: Aaron Kling <webgeek1234@gmail.com>
---
 Documentation/devicetree/bindings/arm/qcom.yaml | 9 +++++++++
 1 file changed, 9 insertions(+)

diff --git a/Documentation/devicetree/bindings/arm/qcom.yaml b/Documentation/devicetree/bindings/arm/qcom.yaml
index d054a8f5632d853509b7cd37f07f02473cf6bf71..ee68963c30eae10fd3b3a5e21bda63ab941893fa 100644
--- a/Documentation/devicetree/bindings/arm/qcom.yaml
+++ b/Documentation/devicetree/bindings/arm/qcom.yaml
@@ -1075,6 +1075,15 @@ properties:
           - const: qcom,qcs8550
           - const: qcom,sm8550
 
+      - items:
+          - enum:
+              - ayntec,odin2
+              - ayntec,odin2mini
+              - ayntec,odin2portal
+              - ayntec,thor
+          - const: qcom,qcs8550
+          - const: qcom,sm8550
+
       - items:
           - enum:
               - qcom,sm8650-hdk

-- 
2.53.0

On Sun, Mar 22, 2026 at 09:05:18PM -0500, Aaron Kling wrote:
> Namely:
> * Odin 2
> * Odin 2 Mini
> * Odin 2 Portal
> * Thor
> 
> Signed-off-by: Aaron Kling <webgeek1234@gmail.com>
> ---
>  Documentation/devicetree/bindings/arm/qcom.yaml | 9 +++++++++
>  1 file changed, 9 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/arm/qcom.yaml b/Documentation/devicetree/bindings/arm/qcom.yaml
> index d054a8f5632d853509b7cd37f07f02473cf6bf71..ee68963c30eae10fd3b3a5e21bda63ab941893fa 100644
> --- a/Documentation/devicetree/bindings/arm/qcom.yaml
> +++ b/Documentation/devicetree/bindings/arm/qcom.yaml
> @@ -1075,6 +1075,15 @@ properties:
>            - const: qcom,qcs8550
>            - const: qcom,sm8550
>  
> +      - items:
> +          - enum:
> +              - ayntec,odin2
> +              - ayntec,odin2mini
> +              - ayntec,odin2portal
> +              - ayntec,thor

I already commented on vendor prefix patch, that you incorrectly moved
it out from this set. This only stalls your patchsets, because none of
the trees will have it thus none will pass any checks.

Best regards,
Krzysztof

On Mon, Mar 23, 2026 at 2:51 AM Krzysztof Kozlowski <krzk@kernel.org> wrote:
>
> On Sun, Mar 22, 2026 at 09:05:18PM -0500, Aaron Kling wrote:
> > Namely:
> > * Odin 2
> > * Odin 2 Mini
> > * Odin 2 Portal
> > * Thor
> >
> > Signed-off-by: Aaron Kling <webgeek1234@gmail.com>
> > ---
> >  Documentation/devicetree/bindings/arm/qcom.yaml | 9 +++++++++
> >  1 file changed, 9 insertions(+)
> >
> > diff --git a/Documentation/devicetree/bindings/arm/qcom.yaml b/Documentation/devicetree/bindings/arm/qcom.yaml
> > index d054a8f5632d853509b7cd37f07f02473cf6bf71..ee68963c30eae10fd3b3a5e21bda63ab941893fa 100644
> > --- a/Documentation/devicetree/bindings/arm/qcom.yaml
> > +++ b/Documentation/devicetree/bindings/arm/qcom.yaml
> > @@ -1075,6 +1075,15 @@ properties:
> >            - const: qcom,qcs8550
> >            - const: qcom,sm8550
> >
> > +      - items:
> > +          - enum:
> > +              - ayntec,odin2
> > +              - ayntec,odin2mini
> > +              - ayntec,odin2portal
> > +              - ayntec,thor
>
> I already commented on vendor prefix patch, that you incorrectly moved
> it out from this set. This only stalls your patchsets, because none of
> the trees will have it thus none will pass any checks.

You mean the checks that passed just fine on v2? This is documented in
the cover letter, which apparently no one ever reads so I wonder why
we even write them; and listed as a dep, which said checks pick up
just fine.

As I have mentioned multiple times, the vendor patch is separate
because I have multiple open series that depend on the vendor and
there's no telling which one will be picked up first.

Aaron

On 23/03/2026 09:39, Aaron Kling wrote:
> On Mon, Mar 23, 2026 at 2:51 AM Krzysztof Kozlowski <krzk@kernel.org> wrote:
>>
>> On Sun, Mar 22, 2026 at 09:05:18PM -0500, Aaron Kling wrote:
>>> Namely:
>>> * Odin 2
>>> * Odin 2 Mini
>>> * Odin 2 Portal
>>> * Thor
>>>
>>> Signed-off-by: Aaron Kling <webgeek1234@gmail.com>
>>> ---
>>>  Documentation/devicetree/bindings/arm/qcom.yaml | 9 +++++++++
>>>  1 file changed, 9 insertions(+)
>>>
>>> diff --git a/Documentation/devicetree/bindings/arm/qcom.yaml b/Documentation/devicetree/bindings/arm/qcom.yaml
>>> index d054a8f5632d853509b7cd37f07f02473cf6bf71..ee68963c30eae10fd3b3a5e21bda63ab941893fa 100644
>>> --- a/Documentation/devicetree/bindings/arm/qcom.yaml
>>> +++ b/Documentation/devicetree/bindings/arm/qcom.yaml
>>> @@ -1075,6 +1075,15 @@ properties:
>>>            - const: qcom,qcs8550
>>>            - const: qcom,sm8550
>>>
>>> +      - items:
>>> +          - enum:
>>> +              - ayntec,odin2
>>> +              - ayntec,odin2mini
>>> +              - ayntec,odin2portal
>>> +              - ayntec,thor
>>
>> I already commented on vendor prefix patch, that you incorrectly moved
>> it out from this set. This only stalls your patchsets, because none of
>> the trees will have it thus none will pass any checks.
> 
> You mean the checks that passed just fine on v2? This is documented in
> the cover letter, which apparently no one ever reads so I wonder why
> we even write them; and listed as a dep, which said checks pick up
> just fine.

Checks will not be fine, imagine this scenario: Bjorn will pick up this
patchset and next will have failures, because there is no vendor prefix
documented in the next.

> 
> As I have mentioned multiple times, the vendor patch is separate

And as I answered to you already twice...

> because I have multiple open series that depend on the vendor and
> there's no telling which one will be picked up first.

...no one will pick up vendor prefix thus your goal will not be
achieved. Nothing in vendor prefix patch explains how should take it to
solve it. People do not take random patches, so if you wanted Rob to
take it, you should have been explicit.

Best regards,
Krzysztof

On 23/03/2026 10:00, Krzysztof Kozlowski wrote:
> On 23/03/2026 09:39, Aaron Kling wrote:
>> On Mon, Mar 23, 2026 at 2:51 AM Krzysztof Kozlowski <krzk@kernel.org> wrote:
>>>
>>> On Sun, Mar 22, 2026 at 09:05:18PM -0500, Aaron Kling wrote:
>>>> Namely:
>>>> * Odin 2
>>>> * Odin 2 Mini
>>>> * Odin 2 Portal
>>>> * Thor
>>>>
>>>> Signed-off-by: Aaron Kling <webgeek1234@gmail.com>
>>>> ---
>>>>  Documentation/devicetree/bindings/arm/qcom.yaml | 9 +++++++++
>>>>  1 file changed, 9 insertions(+)
>>>>
>>>> diff --git a/Documentation/devicetree/bindings/arm/qcom.yaml b/Documentation/devicetree/bindings/arm/qcom.yaml
>>>> index d054a8f5632d853509b7cd37f07f02473cf6bf71..ee68963c30eae10fd3b3a5e21bda63ab941893fa 100644
>>>> --- a/Documentation/devicetree/bindings/arm/qcom.yaml
>>>> +++ b/Documentation/devicetree/bindings/arm/qcom.yaml
>>>> @@ -1075,6 +1075,15 @@ properties:
>>>>            - const: qcom,qcs8550
>>>>            - const: qcom,sm8550
>>>>
>>>> +      - items:
>>>> +          - enum:
>>>> +              - ayntec,odin2
>>>> +              - ayntec,odin2mini
>>>> +              - ayntec,odin2portal
>>>> +              - ayntec,thor
>>>
>>> I already commented on vendor prefix patch, that you incorrectly moved
>>> it out from this set. This only stalls your patchsets, because none of
>>> the trees will have it thus none will pass any checks.
>>
>> You mean the checks that passed just fine on v2? This is documented in
>> the cover letter, which apparently no one ever reads so I wonder why
>> we even write them; and listed as a dep, which said checks pick up
>> just fine.
> 
> Checks will not be fine, imagine this scenario: Bjorn will pick up this
> patchset and next will have failures, because there is no vendor prefix
> documented in the next.

There are also more subtle problems here.

Because you included it as b4 deps, multiple maintainers might pull the
same patchset if they are not careful and do not notice the pull of
dependency. If that happens, you achieved nothing by decoupling it and
it is the same as it was included in every patchset.

I, for example, do not take patches with dependencies, so that would be
a blocker, so again you achieved nothing. I don't know about Bjorn, though.

OTOH, since you have a b4 dep here and bot checks supposedly pass,
maintainer might just pull this patchset (without dependency in cherry
pick mode of b4) and not notice the failures.

> 
>>
>> As I have mentioned multiple times, the vendor patch is separate
> 
> And as I answered to you already twice...
> 
>> because I have multiple open series that depend on the vendor and
>> there's no telling which one will be picked up first.
> 
> ...no one will pick up vendor prefix thus your goal will not be
> achieved. Nothing in vendor prefix patch explains how should take it to
> solve it. People do not take random patches, so if you wanted Rob to
> take it, you should have been explicit.



Best regards,
Krzysztof

On Mon, Mar 23, 2026 at 4:04 AM Krzysztof Kozlowski <krzk@kernel.org> wrote:
>
> On 23/03/2026 10:00, Krzysztof Kozlowski wrote:
> > On 23/03/2026 09:39, Aaron Kling wrote:
> >> On Mon, Mar 23, 2026 at 2:51 AM Krzysztof Kozlowski <krzk@kernel.org> wrote:
> >>>
> >>> On Sun, Mar 22, 2026 at 09:05:18PM -0500, Aaron Kling wrote:
> >>>> Namely:
> >>>> * Odin 2
> >>>> * Odin 2 Mini
> >>>> * Odin 2 Portal
> >>>> * Thor
> >>>>
> >>>> Signed-off-by: Aaron Kling <webgeek1234@gmail.com>
> >>>> ---
> >>>>  Documentation/devicetree/bindings/arm/qcom.yaml | 9 +++++++++
> >>>>  1 file changed, 9 insertions(+)
> >>>>
> >>>> diff --git a/Documentation/devicetree/bindings/arm/qcom.yaml b/Documentation/devicetree/bindings/arm/qcom.yaml
> >>>> index d054a8f5632d853509b7cd37f07f02473cf6bf71..ee68963c30eae10fd3b3a5e21bda63ab941893fa 100644
> >>>> --- a/Documentation/devicetree/bindings/arm/qcom.yaml
> >>>> +++ b/Documentation/devicetree/bindings/arm/qcom.yaml
> >>>> @@ -1075,6 +1075,15 @@ properties:
> >>>>            - const: qcom,qcs8550
> >>>>            - const: qcom,sm8550
> >>>>
> >>>> +      - items:
> >>>> +          - enum:
> >>>> +              - ayntec,odin2
> >>>> +              - ayntec,odin2mini
> >>>> +              - ayntec,odin2portal
> >>>> +              - ayntec,thor
> >>>
> >>> I already commented on vendor prefix patch, that you incorrectly moved
> >>> it out from this set. This only stalls your patchsets, because none of
> >>> the trees will have it thus none will pass any checks.
> >>
> >> You mean the checks that passed just fine on v2? This is documented in
> >> the cover letter, which apparently no one ever reads so I wonder why
> >> we even write them; and listed as a dep, which said checks pick up
> >> just fine.
> >
> > Checks will not be fine, imagine this scenario: Bjorn will pick up this
> > patchset and next will have failures, because there is no vendor prefix
> > documented in the next.
>
> There are also more subtle problems here.
>
> Because you included it as b4 deps, multiple maintainers might pull the
> same patchset if they are not careful and do not notice the pull of
> dependency. If that happens, you achieved nothing by decoupling it and
> it is the same as it was included in every patchset.
>
> I, for example, do not take patches with dependencies, so that would be
> a blocker, so again you achieved nothing. I don't know about Bjorn, though.
>
> OTOH, since you have a b4 dep here and bot checks supposedly pass,
> maintainer might just pull this patchset (without dependency in cherry
> pick mode of b4) and not notice the failures.
>
> >
> >>
> >> As I have mentioned multiple times, the vendor patch is separate
> >
> > And as I answered to you already twice...
> >
> >> because I have multiple open series that depend on the vendor and
> >> there's no telling which one will be picked up first.
> >
> > ...no one will pick up vendor prefix thus your goal will not be
> > achieved. Nothing in vendor prefix patch explains how should take it to
> > solve it. People do not take random patches, so if you wanted Rob to
> > take it, you should have been explicit.

You told me on multiple tegra series to split things and list merge
dependencies in the cover letter. I have listed in this cover letter
that the vendor patch must be merged before anything from this series
is picked up. Why is this any different from what you kept telling me
before? Whichever binding patch gets cleared for merge first will
trigger the dependency of merging the vendor patch. And as long as a
message is generated on that patch that it has been picked up, other
series with that dependency would not cause a duplicate.

What would the alternative be? Say the vendor patch gets added to this
series. Then I would have a driver series that would have to list this
as a b4 dep for checks to continue to pass. Making a dt series that is
otherwise unrelated a requirement for that driver to be merged. That
seems even worse. Or much worse, I would be unable to submit such
drivers at all until this has been picked up.

Aaron

On 23/03/2026 17:03, Aaron Kling wrote:
>>>>
>>>> As I have mentioned multiple times, the vendor patch is separate
>>>
>>> And as I answered to you already twice...
>>>
>>>> because I have multiple open series that depend on the vendor and
>>>> there's no telling which one will be picked up first.
>>>
>>> ...no one will pick up vendor prefix thus your goal will not be
>>> achieved. Nothing in vendor prefix patch explains how should take it to
>>> solve it. People do not take random patches, so if you wanted Rob to
>>> take it, you should have been explicit.
> 
> You told me on multiple tegra series to split things and list merge
> dependencies in the cover letter. I have listed in this cover letter
> that the vendor patch must be merged before anything from this series
> is picked up. Why is this any different from what you kept telling me
> before? Whichever binding patch gets cleared for merge first will

Because these patches in tegra will be picked up. Vendor prefix won't.
Let's reverse the problem - who should pick up such vendor prefix patch
without user and explanation, and why anyone should do it?

> trigger the dependency of merging the vendor patch. And as long as a
> message is generated on that patch that it has been picked up, other
> series with that dependency would not cause a duplicate.
> 
> What would the alternative be? Say the vendor patch gets added to this
> series. Then I would have a driver series that would have to list this

Could be. I gave you other alternative - "you should have been explicit".

> as a b4 dep for checks to continue to pass. Making a dt series that is
> otherwise unrelated a requirement for that driver to be merged. That
> seems even worse. Or much worse, I would be unable to submit such
> drivers at all until this has been picked up.
> 
> Aaron


Best regards,
Krzysztof