Re: [PATCH v8 02/18] dt-bindings: media: qcom,x1e80100-camss: Convert from inline PHY definitions to PHY handles
From: Krzysztof Kozlowski
Date: Thu Feb 26 2026 - 04:50:39 EST
On 26/02/2026 10:40, Bryan O'Donoghue wrote:
> On 26/02/2026 09:33, Krzysztof Kozlowski wrote:
>> On 26/02/2026 10:27, Bryan O'Donoghue wrote:
>>> On 26/02/2026 07:07, Krzysztof Kozlowski wrote:
>>>> No, it does not allow that. You cannto change the ABI.
>>>>
>>>> That's why I reminded multiple times before reviewing new CAMSS bindings
>>>> for Milos and something more. Because once it gets accepted, you cannot
>>>> change it anymore without valid reason. And there is no valid reason
>>>> here provided. I kept these patches in staging/waiting for long
>>>> enough...
>>>
>>> I thought your policy was - a dtsi had to have it, which we don't yet have.
>>
>> And from where did you take that policy? I am pretty sure my each
>> comment is about ABI. Heh, I even commented few times about implied ABI
>> purely based on kernel, without DTS.
>
> Correct me if I'm wrong. I thought we had discussed either @ the Linaro
> Dublin meet or the Linaro Amsterdam meet that changing upstream YAML
> would be feasible _if_ you could show there was no dependency on it -
> say u-boot, FreeBSD etc.
And I mentioned multiple caveats and restrictions. Do you quote them
here or just took the first part of sentence before ", but only ..."?
Anyway, whatever spoken is improvable and I am sure I did not give such
permissions, maybe except that Dublin meeting was in 2024 thus before
the release of previous user, so before v6.16, so of course you can
still reshape unreleased ABI. And then you released it closing the
discussion.
>
> I completely understand why you'd say for a UART definition its an ABI
> since quite likely another OS might consume the YAML but, I also think
> nobody but upstream Linux cares about this binding at all and our only
> actual user is upstream dtsi in Linux, which doesn't exist yet.
Half of the comments responding to DT maintainers are "but no one
cares". Well, I do care, so that's it. If I start analyzing each case
for possible exceptions I would spend too much time on it. So follow
documented and expressed in written rules.
Best regards,
Krzysztof