Re: [RFC PATCH 0/3] media: qcom: camss: support for empty endpoint nodes

[Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>]

On 12/31/25 9:34 AM, Vladimir Zapolskiy wrote:
> On 12/31/25 05:02, Richard Acayan wrote:
>> On Tue, Dec 30, 2025 at 10:18:39AM +0200, Vladimir Zapolskiy wrote:
>>> On 12/30/25 04:27, Richard Acayan wrote:
>>>> This series adds support for empty endpoint nodes. It is currently RFC
>>>> because it continues an ongoing discussion on how to selectively connect
>>>> some CAMSS ports to cameras and leave others disconnected.
>>>>
>>>> The SDM670 patches are for a full example. If agreed on, this should
>>>> expand to SoCs that have CAMSS.
>>>>
>>>> Example SoC dtsi:
>>>>
>>>>     camss: isp@00000000 {
>>>>         ...
>>>>
>>>>         status = "disabled";
>>>>
>>>>         ports {
>>>>             #address-cells = <1>;
>>>>             #size-cells = <0>;
>>>>
>>>>             port@0 {
>>>>                 reg = <0>;
>>>>
>>>>                 camss_endpoint0: endpoint {
>>>>                 };
>>>>             };
>>>
>>> I do not see this device tree node layout as a valid one. A 'port' provides
>>> an interface description (an option), and an 'endpoint' declares a connection
>>> over a port (the accepted option).
>>>
>>>  From dtschema/schemas/graph.yaml:
>>>
>>>      Each port node contains an 'endpoint' subnode for each remote device port
>>>      connected to this port.
>>>
>>> This is violated in the example given by you above, when a remote device along
>>> with its ports is just missing, thus there is no connection. A forced alternative
>>> reading may (or will) break the legacy, so in this particular case you shall
>>> start from making a change to the shared graph.yaml documentation, since it's
>>> all not about CAMSS or even linux-media specifics.
>>
>> So, if endpoints MUST/SHALL (in IETF RFC 2119 terms) have a remote, then
>> would it be acceptable to label the ports instead, so a board DTS can
>> specify its own fully connected endpoint(s) under the port labels?

I don't know if they MUST, but it IS convenient from the maintainer
perspective since it generally lets people make less mistakes and reduces
copypasta..

We've successfully used this ""model"" for Qualcomm display nodes, as well as
(both non-/Qualcomm) USB-C graphs

> It could be done. For the record, the solution is not to "label the ports
> instead", but the preliminary added endpoints should be gone, and it implies
> that the labels to the endpoints are gone also.
> 
>>
>> The labels to ports aren't looking as "excessive"[1] as they used to be.
>> Is the original review comment on port labels still relevant?
>>
>> [1] https://lore.kernel.org/r/565d14e1-1478-4a60-8f70-a76a732cde97@linaro.org
> 
> It's relevant with a modulus of 'likely', it's so secondary that I've issued
> my RB at that time. You can write a proper dt graph layout without using dt
> labels, and since it's expected that you touch &camss anyway to change its
> 'status' property value etc., you may add ports and endpoints under the same
> labelled &camss device tree node at once. There is no rule to use some labels
> no matter what, but technically you may introduce port labels and add endpoints
> by a port label, this approach is practically found e.g. with Rockchip or
> TI ISP device tree nodes.

Referring to nodes through labels is generally agreed to be the best-practice
given it's the only way that ensures at compile-time that the referenced node
actually exists.

At the end of the day, this is essentially syntax sugar. What we put in the
DT must be somehow interpretable by the OS, and it just so happens that this
doesn't really introduce much complexity while having the aforementioned
benefits

Konrad