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

[Bryan O'Donoghue]

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.

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.

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

---
bod