Re: [PATCH v13 3/5] media: qcom: camss: Add support for PHY API devices
Nihal Kumar Gupta <[email protected]>
| Newsgroups | org.kernel.vger.linux-media,org.infradead.lists.linux-phy,org.kernel.vger.linux-arm-msm,org.kernel.vger.linux-clk,org.kernel.vger.linux-devicetree,org.kernel.vger.linux-kernel |
|---|---|
| Message-ID | <[email protected]> |
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 <[email protected]> # Glymur-CRD and Monaco EVK
---
Regards,
Nihal Kumar Gupta