From: Krzysztof Kozlowski <krzk@kernel.org>
To: Michael Riesch <michael.riesch@collabora.com>
Cc: Mauro Carvalho Chehab <mchehab@kernel.org>,
Sakari Ailus <sakari.ailus@linux.intel.com>,
Laurent Pinchart <laurent.pinchart@ideasonboard.com>,
Frank Li <Frank.li@nxp.com>, Rob Herring <robh@kernel.org>,
Krzysztof Kozlowski <krzk+dt@kernel.org>,
Conor Dooley <conor+dt@kernel.org>,
Heiko Stuebner <heiko@sntech.de>,
Kever Yang <kever.yang@rock-chips.com>,
Collabora Kernel Team <kernel@collabora.com>,
linux-media@vger.kernel.org, devicetree@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-rockchip@lists.infradead.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/4] media: dt-bindings: rockchip,rk3568-mipi-csi2: add rk3588 compatible
Date: Mon, 9 Mar 2026 10:11:07 +0100 [thread overview]
Message-ID: <7a48529e-009f-40ef-810d-b90226bade0d@kernel.org> (raw)
In-Reply-To: <eaec4b1c-469c-4f81-884b-3308aa85633f@collabora.com>
On 09/03/2026 09:50, Michael Riesch wrote:
> Hi Krzysztof,
>
> On 3/7/26 16:33, Krzysztof Kozlowski wrote:
>> On Fri, Mar 06, 2026 at 03:09:48PM +0100, Michael Riesch wrote:
>>> The RK3588 MIPI CSI-2 receivers are compatible to the ones found in
>>> the RK3568. However, their integration in the respective SoC may be
>>> different when it comes to the (currently not implemented) split
>>
>> All this says they are compatible, so express it.
>
> ..express it... how exactly? In the commit message? Or what do you mean
> exactly?
See DTS 101 presentation or DT spec. Compatibility is expressed by using
fallbacks.
>
>>> DPHY feature. Therefore, add the RK3588 compatible to allow for
>>> future differentiation.
>>
>> This I do not understand. If you just copy standard rules from
>> writing-bindings, then no, don't do that. It's obvious and there is
>> never a need to repeat any standard/common rule. If you want to say
>> devices are not compatible, then say that explicitly.
>
> It's a bit of a complicated story. To keep it short, the RK3568 and the
> RK3588 MIPI CSI-2 receivers are compatible at least right now. In
> future, this may or may not change. This depends on how this split DPHY
> integration is implemented -- and we won't know that for some time.
> Right now I expect that the phys property will become optional when this
> happens (at least for the RK3568).
This does not match at all commit msg. Using fallback allows future
differentiation, so "I will not use fallback for future differentiation"
is obviously incorrect argument.
>
> What is the safe bet here? Going for a fallback compatible and adjust
> everything when the split DPHY feature is implemented?
>
> Best regards,
> Michael
>
Best regards,
Krzysztof
next prev parent reply other threads:[~2026-03-09 9:11 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-06 14:09 [PATCH 0/4] media: synopsys: csi2rx: add support for rk3588 variant Michael Riesch via B4 Relay
2026-03-06 14:09 ` [PATCH 1/4] media: dt-bindings: rockchip,rk3568-mipi-csi2: add rk3588 compatible Michael Riesch via B4 Relay
2026-03-07 15:33 ` Krzysztof Kozlowski
2026-03-09 8:50 ` Michael Riesch
2026-03-09 9:11 ` Krzysztof Kozlowski [this message]
2026-03-09 15:44 ` Frank Li
2026-03-06 14:09 ` [PATCH 2/4] media: synopsys: csi2rx: add support for rk3588 variant Michael Riesch via B4 Relay
2026-03-07 15:35 ` Krzysztof Kozlowski
2026-03-06 14:09 ` [PATCH 3/4] arm64: dts: rockchip: add mipi csi-2 receiver nodes to rk3588 Michael Riesch via B4 Relay
2026-03-06 14:09 ` [PATCH 4/4] arm64: defconfig: enable designware mipi csi-2 receiver Michael Riesch via B4 Relay
2026-03-07 15:34 ` Krzysztof Kozlowski
2026-03-09 9:02 ` Michael Riesch
2026-03-09 9:11 ` Krzysztof Kozlowski
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=7a48529e-009f-40ef-810d-b90226bade0d@kernel.org \
--to=krzk@kernel.org \
--cc=Frank.li@nxp.com \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=heiko@sntech.de \
--cc=kernel@collabora.com \
--cc=kever.yang@rock-chips.com \
--cc=krzk+dt@kernel.org \
--cc=laurent.pinchart@ideasonboard.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-media@vger.kernel.org \
--cc=linux-rockchip@lists.infradead.org \
--cc=mchehab@kernel.org \
--cc=michael.riesch@collabora.com \
--cc=robh@kernel.org \
--cc=sakari.ailus@linux.intel.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox