Re: [PATCH 1/3] phy: core: add generic MIPI C-PHY configuration API

[Anusha Arun Nandi]

On 10/22/2026 7:15 PM, Bryan O'Donoghue wrote:
> On 23/10/2026 01:33, Anusha Arun Nandi wrote:
>>>> +    if (!cfg || !lanes)
>>>> +        return -EINVAL;
>>> Lanes must be a multiple of three to be valid, at least for your three
>>> submissions to be logically consistent, this statement must be so.
>>>
>> I will update the name of lanes to data_lanes in
>> phy_configure_opts_mipi_cphy struct.
>> I will add more sanity checks for data_lanes > 3, as C-PHY supports 3
>> data lanes only.
> 
> Sorry the only thing weirder than arguing with other people on the
> internet is arguing with yourself.
> 
> I argued myself down from this.
> 
> =>
> 
> One CPHY lane is 3 three wires. So data-lanes = <1> means three wire
> that only the PHY driver understands.
> 
> We communicate in lanes not in pads. There is no meaningful way to
> specify pads in DT - only lanes.
> 
> Which means lanes - I think we should follow what struct phy_mipi_dphy
> already models for us:
> 
> /**
>  * struct phy_configure_opts_mipi_dphy - MIPI D-PHY configuration set
>  *
>  * This structure is used to represent the configuration state of a
>  * MIPI D-PHY phy.
>  */
> struct phy_configure_opts_mipi_dphy {
> 
>         /**
>          * @lanes:
>          *
>          * Number of active, consecutive, data lanes, starting from
>          * lane 0, used for the transmissions.
>          */
>         unsigned char           lanes;
> };
> 
> For example in DPHY lane == "two pads on the SoC" so for us in CPHY mode
> lane == "three pads on the SoC", there's no need to deviate from that.
> 
Ack. We will keep it as lanes.
> The CSID needs to know the symbol rate - so that it can vote on the
> appropriate NOC/CamNOC clocks/rails but... does the PHY driver itself
> need to know that ? It does not, symbol_rate is not required in this
> struct no more than it is in DPHY.
> 
Yes agree. I was thinking the same. We would not need the symbol_rate in
the struct.

> Sample principle.
> 
> So _really_ thinking about this I suggest
> 
> - Following the DPHY example
> - Including all of the CPHY specific timings
>   The ones you posted, plus the few I found missing
>   Any other relevant CPHY timings we may have missed
> - Include the helper functions in drivers/phy/phy-core-mipi-cphy.c
>   IMO we should use defines not hard-coded constants for the
>   specification of the timings here, unlike the DPHY code
> 
These comments will be addressed in the next version.

> ---
> bod