Re: [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@xxxxxxxxxx/
> >
> > 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