Re: [PATCH v3 1/5] dt-bindings: arm: qcom: Add AYN QCS8550 Devices

[Krzysztof Kozlowski]

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@xxxxxxxxxx> 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@xxxxxxxxx>
>>>> ---
>>>>  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