From: Richard Acayan <mailingradian@gmail.com>
To: Vladimir Zapolskiy <vladimir.zapolskiy@linaro.org>
Cc: Robert Foss <rfoss@kernel.org>, Todor Tomov <todor.too@gmail.com>,
Bryan O'Donoghue <bryan.odonoghue@linaro.org>,
Mauro Carvalho Chehab <mchehab@kernel.org>,
Rob Herring <robh@kernel.org>,
Krzysztof Kozlowski <krzk+dt@kernel.org>,
Conor Dooley <conor+dt@kernel.org>,
Bjorn Andersson <andersson@kernel.org>,
Konrad Dybcio <konradybcio@kernel.org>,
linux-arm-msm@vger.kernel.org, linux-media@vger.kernel.org,
devicetree@vger.kernel.org
Subject: Re: [RFC PATCH 0/3] media: qcom: camss: support for empty endpoint nodes
Date: Tue, 30 Dec 2025 22:02:12 -0500 [thread overview]
Message-ID: <aVSSNGCtvcYCTylu@rdacayan> (raw)
In-Reply-To: <1fa74da9-bd3e-43c6-afbc-8cfcbb93af93@linaro.org>
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?
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
next prev parent reply other threads:[~2025-12-31 3:01 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-12-30 2:27 [RFC PATCH 0/3] media: qcom: camss: support for empty endpoint nodes Richard Acayan
2025-12-30 2:27 ` [RFC PATCH 1/3] dt-bindings: media: camss: sdm670: Make endpoint properties optional Richard Acayan
2025-12-30 7:30 ` Krzysztof Kozlowski
2025-12-30 2:27 ` [RFC PATCH 2/3] media: qcom: camss: allow endpoints with no remote Richard Acayan
2025-12-30 2:27 ` [RFC PATCH 3/3] arm64: dts: qcom: sdm670: remove status properties of camss endpoints Richard Acayan
2025-12-30 8:18 ` [RFC PATCH 0/3] media: qcom: camss: support for empty endpoint nodes Vladimir Zapolskiy
2025-12-31 3:02 ` Richard Acayan [this message]
2025-12-31 8:34 ` Vladimir Zapolskiy
2026-01-30 11:31 ` Konrad Dybcio
2025-12-30 9:40 ` Bryan O'Donoghue
2025-12-31 2:20 ` Richard Acayan
2025-12-31 3:08 ` Bryan O'Donoghue
2026-01-10 1:03 ` Richard Acayan
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=aVSSNGCtvcYCTylu@rdacayan \
--to=mailingradian@gmail.com \
--cc=andersson@kernel.org \
--cc=bryan.odonoghue@linaro.org \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=konradybcio@kernel.org \
--cc=krzk+dt@kernel.org \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-media@vger.kernel.org \
--cc=mchehab@kernel.org \
--cc=rfoss@kernel.org \
--cc=robh@kernel.org \
--cc=todor.too@gmail.com \
--cc=vladimir.zapolskiy@linaro.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.