Re: [PATCH v4 2/2] phy: qcom-mipi-csi2: Add a CSI2 MIPI DPHY driver

[Bryan O'Donoghue]

On 19/03/2026 14:05, Neil Armstrong wrote:
> > There's no reason to remove that from CAMSS - it would be an ABI break in user-space anyway.
> >
> > The media entity in CAMSS msm_csiphyX handles format negotiation and pipeline routing. The PHY driver handles electrical configuration. They don't conflict and there multiple cited examples of this upstream already.
> If csiphy component was only handling  electrical configuration, the only code handling csiphy would be phy API calls, not be part of the pipeline configuration. Today, it's a media element
>
> The whole CAMSS architecture is wrong, it should be modular, each hardware module should be an independent driver and all be connected via port/endpoint and configured with the media controller API.
>
> If you_really_ want to move the "electrical configuration" part of the CSPIPHY out of camss frankendriver, fine, then first just create an internal PHY device as an aux device, then continue migrating_all_ CAMSS components into independent driver modules, then in the end re-architecture the whole DT description by adding a node per component with a proper port/endpoint representation to be configured via the media controller API.
>
> Neil

Re-architecting the whole driver without breaking legacy code is well 
out of scope.

I'd note making a standalone CSIPHY driver 100% fits in with such a 
goal. I don't think I've seen one good reason why CAMSS needs an aux 
device and can't follow established upstream paradigms for Cadence and 
Rockchip.

Anyway I take the feedback on polarities and will in v5 of this patch 
address.

---
bod