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

[Bryan O'Donoghue <bryan.odonoghue@linaro.org>]

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