[PATCH v8 1/2] dt-bindings: phy: qcom: Add CSI2 C-PHY/DPHY schema

[Vladimir Zapolskiy]

On 7/2/26 11:46, Bryan O'Donoghue wrote:
> On 02/07/2026 09:31, Vladimir Zapolskiy wrote:
>>>>> phy-cells = 1 with CPHY/DPHY specified in the consumer, as was Rob's
>>>>> suggestion will specify the mode.
>>>>
>>>> This cell is just not needed, and unneeded complexity should not be
>>>> added.
>>>
>>> I'm going to stick to Rob's initial guidance on this.
>>>
>>> https://lore.kernel.org/linux-media/20250710230846.GA44483-
>>> robh at kernel.org/
>>>
>>
>> Sure, the discussion will be continued abouve v9 of the series, it's
>> just a chance to do it now. Rob properly pointed out, that the invented
>> "phy-type" is not needed at all.
> 
> I'll quote here
> 
>   >> +  phy-type:
>   >> +    description: D-PHY or C-PHY mode
>   >> +    enum: [ 10, 11 ]
>   >> +    $ref: /schemas/types.yaml#/definitions/uint32
> 
>   > Perhaps putting this in phy cells would be better because the consumer
>   > decides on the mode.
> 
> A clear instruction which I'm implementing.

It has no contradiction with what I've said above, you have a chance to
discuss the matter now or at v9 time.

>> Ther fact is that the whole placement of the CSIPHY to phy subsystem
>> looks execessive, since you add a driver for a media device, there will
>> be nothing PHY driver specific left in the CSIPHY driver but name.
> No, a block with its own pins, external voltage rails, even its own
> specific votes to scale individual clocks, is a distinct PHY.
> 
> There will be no further CSIPHY init sequences getting buried in CAMSS.
> It is well past time to dispense with the monolith.
> 

Again, there is no contradiction with what I've said above, so far there
is no argument to support CSIPHY driver registration within phy framework.

-- 
Best wishes,
Vladimir