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

[Aaron Kling]

On Mon, Mar 23, 2026 at 4:04 AM Krzysztof Kozlowski <krzk@xxxxxxxxxx> 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@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.

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