Re: [PATCH 2/6] dt-bindings: media: camss: Add qcom,kaanapali-camss binding

[Bryan O'Donoghue <bryan.odonoghue@linaro.org>]

On 20/10/2025 18:37, Vijay Kumar Tumati wrote:
> Hi @Bryan, @Krzyszto, just my two cents. I think we should consider 
> separating CSIPHY, CSID, IFE and IFE Lite into distinct DT nodes. Having 
> a modular DT structure brings in several advantages,
> 
>  1. Simple to manage with much better readability.
>  2. Better control to disable certain HW modules from DT.
>  3. Less error prone as we don't need to maintain long lists of clocks
>     or other resources against their names. Accordingly, easy to review.
>  4. No need to maintain resource lists within the CAMSS driver to
>     identify the resources specific to the HW block. Offers centralized
>     control for the HW resources.
>  5. Allows re use between the platforms when a same version of a subset
>     of HW modules is carried over to future chip sets.
>  6. Is more scalable when we add more functionality to the CAMSS driver.
>  7. Finally, it brings in parallel development ability with engineers
>     (within the local teams) working on different HW modules within
>     camera subsystem.
> 
> If not for the current patches in the pipeline, if you are comfortable 
> with this approach, we will try to push the changes for the future chip 
> sets with the modular bindings, leaving the existing SOC drivers and 
> bindings untouched (if that's recommended). Please let us know your 
> thoughts. Thanks.

I think the Rockchip breaking up of blocks is structurally nice and how 
you would do things if you were adding stuff in from scratch.

Old Irish Joke:
Man in car stops asks local: "How do I get to Tralee"
Local scratches head under cap: "Well; I wouldn't start from here"

We have existing bindings and one message that has been repeated is that 
new bindings should follow old bindings of a similar class.

There's a good argument to separate out the CSIPHY - because it has 
distinct power-rails and has a real-world effect for users - in that 
their PCB.

It would really be up to yourselves to justify why it is a whole new 
binding is required i.e. what benefit does it actually bring, and to 
show, prove, that existing users of this driver either benefit or don't 
suffer i.e. doing work for old silicon too, not just the new stuff.

If the only objective you have is to facilitate co-existence of a 
downstream driver with upstream bindings.

Anyway there's absolutely no reason to hold up this series or any 
subsequent series on a hypothetical rewrite unless/until that rewrite 
gets proposed, reviewed and applied.

---
bod