Re: [PATCH v8 02/18] dt-bindings: media: qcom,x1e80100-camss: Convert from inline PHY definitions to PHY handles

[Krzysztof Kozlowski]

On 26/02/2026 11:06, Bryan O'Donoghue wrote:
> On 26/02/2026 09:50, Krzysztof Kozlowski wrote:
>> 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.
> Well, is there a way to support both then ?

I would just not touch x1e80100, but if you want then probably binding
should stay backwards compatible, where you keep all properties intact
and only add csiphy nodes.


> 
> Right now I have csiphy and their registers listed in the camss block.
> 
> I could add phys = <> as optional in the schema. Is there any reason to 
> stop adding adjacent csiphy nodes ?

I think no.

> 
> isp@addr {
> 	regs = 0xCSID0,
> 	       0xCSIPH1;
> 	reg-names = "csidX",
> 		    "csiphy0";
> };
> 
> csiphy@CSIPHY1 {}
> 
> I'm not sure if this is against DT rules.
> 
> The iommu items _should_ be fine as its maxItems so I can just set that 
> to five instead of eight in the dtsi.
> 
> ---
> bod


Best regards,
Krzysztof