From: Michael Riesch <michael.riesch@collabora.com>

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
DPHY feature. Therefore, add the RK3588 compatible to allow for
future differentiation.

Signed-off-by: Michael Riesch <michael.riesch@collabora.com>
---
 Documentation/devicetree/bindings/media/rockchip,rk3568-mipi-csi2.yaml | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/media/rockchip,rk3568-mipi-csi2.yaml b/Documentation/devicetree/bindings/media/rockchip,rk3568-mipi-csi2.yaml
index 2c2bd87582eb..5f8014da31ca 100644
--- a/Documentation/devicetree/bindings/media/rockchip,rk3568-mipi-csi2.yaml
+++ b/Documentation/devicetree/bindings/media/rockchip,rk3568-mipi-csi2.yaml
@@ -18,6 +18,7 @@ properties:
   compatible:
     enum:
       - rockchip,rk3568-mipi-csi2
+      - rockchip,rk3588-mipi-csi2
 
   reg:
     maxItems: 1

-- 
2.39.5

On Fri, Mar 06, 2026 at 03:09:48PM +0100, Michael Riesch via B4 Relay wrote:
> From: Michael Riesch <michael.riesch@collabora.com>
>
> 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
> DPHY feature. Therefore, add the RK3588 compatible to allow for
> future differentiation.
>
> Signed-off-by: Michael Riesch <michael.riesch@collabora.com>
> ---
>  Documentation/devicetree/bindings/media/rockchip,rk3568-mipi-csi2.yaml | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/Documentation/devicetree/bindings/media/rockchip,rk3568-mipi-csi2.yaml b/Documentation/devicetree/bindings/media/rockchip,rk3568-mipi-csi2.yaml
> index 2c2bd87582eb..5f8014da31ca 100644
> --- a/Documentation/devicetree/bindings/media/rockchip,rk3568-mipi-csi2.yaml
> +++ b/Documentation/devicetree/bindings/media/rockchip,rk3568-mipi-csi2.yaml
> @@ -18,6 +18,7 @@ properties:
>    compatible:
>      enum:
>        - rockchip,rk3568-mipi-csi2
> +      - rockchip,rk3588-mipi-csi2

Since driver is exact same as rockchip,rk3568-mipi-csi2, so

oneOf:
  enum
    - rockchip,rk3568-mipi-csi2
  items:
    - enum
        - rockchip,rk3588-mipi-csi2
    - const: rockchip,rk3568-mipi-csi2

So, needn't change drivers.

Frank
>
>    reg:
>      maxItems: 1
>
> --
> 2.39.5
>
>

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.

> 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.

Best regards,
Krzysztof

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?

>> 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).

What is the safe bet here? Going for a fallback compatible and adjust
everything when the split DPHY feature is implemented?

Best regards,
Michael

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