Re: [PATCH 1/2] dt-bindings: media: qcom,glymur-camss: Use CSIPHY indices for ports

[Krzysztof Kozlowski <krzk@kernel.org>]

On 12/11/2026 15:22, Nihal Kumar Gupta wrote:
> 
> 
> On 09-11-2026 11:35, Nihal Kumar Gupta wrote:
>>> So yes, we could argue that the port ID itself has no inherent
>>> meaning, but it acquires meaning through the convention we define,
>>> since we still need a way to map DT ports to CAMSS input IDs. What is
>>> really changing here is the convention used to describe that mapping.
>>> So, for Hamoa, ports { 0, 1, 2, 3 } would map to CAMSS PHY inputs { 0,
>>> 1, 2, 4 }, while for Glymur, ports { 0, 1, 2 } would map to CAMSS PHY
>>> inputs { 0, 1, 4 }.
>>>
>> Thanks Loic, Bryan, Krzysztof and Vladimir for the discussion.
>>
>> Krzysztof, understood on the DT binding concern. I should have got clear DT
>> maintainer agreement before proposing a binding semantic change, and I will
>> keep that in mind for future changes.
>>
>> Based on the discussion, I agree that for standalone PHY CAMSS DT input ports
>> should be logical and linear. For Glymur, that means using ports@0-2 { 0, 1, 2 },
>> and keep the mapping to hardware PHY indices { 0, 1, 4 } inside the driver.
>>
>> Krzysztof, does this direction sound aligned to you? If yes, I will respin
>> accordingly and make sure the commit message documents the logical-port to
>> hardware-PHY mapping clearly.
>>
> 
> Krzysztof, the Glymur CAMSS binding is already merged, but no upstream
> DTS consumes it yet. The current example uses port@3 for CSIPHY4.
> 
> For the binding, would you prefer keeping the existing "^port@[0-3]$"
> range, or tightening it to "^port@[0-2]$" and using logical ports
> port@0, port@1 and port@2 in the example?
> 

Just explain in commit msg there is no port@3, because there are only
three phys.

Best regards,
Krzysztof