[PATCH v13 3/5] media: qcom: camss: Add support for PHY API devices

[Nihal Kumar Gupta]

On 30-07-2026 02:01, Bryan O'Donoghue wrote:
> So I don't think this model is in-keep with established DT practices - if a driver needs to parse a property it needs to have that property in the device node it handles.
> 
> So with data-lanes per existing camss bindings in the IFE/CSID node everything though should work as-is for you.
> 
> https://gitlab.com/Linaro/arm64-laptops/linux/-/tree/arm64-laptops-v7.2-rc2-camss-v11?ref_type=heads
> 
> https://gitlab.com/Linaro/arm64-laptops/linux/-/blob/arm64-laptops-v7.2-rc2-camss-v11/arch/arm64/boot/dts/qcom/x1-crd.dtsi?ref_type=heads#L947
> 
> &camss {
>     status = "okay";
Thanks for the quick response, Bryan.

Confirmed working.
Root cause: I had data-lanes only in csiphy4_in_ep, not in camss_csiphy4_inep.
CAMSS parses its own endpoint — with no data-lanes, lanes_used=0, vep.bus_type
stayed UNKNOWN, bus_type check hard-failed with -EINVAL. That's what led to my patch.

Dropping it; fwnode_device_is_available() fix going via your patch as Co-developed-by.

Tested-by: Nihal Kumar Gupta <nihal.gupta at oss.qualcomm.com> # Glymur-CRD and Monaco EVK

---
Regards,
Nihal Kumar Gupta