dtoverlay: no change to one fragment's target renders `cam0` option unusable

[michalfita]

Is this the right place for my bug report? Yes, dtoverlay was working, but stopped on fresh installation of Raspbery Pi OS 64-bit.

Describe the bug It was working OK last week, stopped this week after reinstallation of the Raspberry Pi OS. The cam0 option passed now doesn't seem to amend the target = <&i2c_csi_dsi1>; to target = <&i2c_csi_dsi0>; properly. This is on my own overlay.

To reproduce Following DTS:

// SPDX-License-Identifier: GPL-2.0-only
// Definitions for OVA one module on VC I2C bus
/dts-v1/;
/plugin/;

#include <gpio.h>

/{
    compatible = "brcm,bcm2835";

    fragment@0 {
        target = <&i2c0if>;
        __overlay__ {
            status = "okay";
        };
    };

    fragment@2 {
        target = <&i2c0mux>;
        __overlay__ {
            status = "okay";
        };
    };

    i2c_frag: fragment@100 {
        target = <&i2c_csi_dsi1>;
        __overlay__ {
            #address-cells = <1>;
            #size-cells = <0>;
            status = "okay";

            cam_node: ovaone@54 {
                compatible = "opteran,ovaone";
                reg = <0x54>;
                status = "disabled";

                VIN-supply = <&cam_dummy_reg>;  /* 5.1v, not fed from RPi 5 */

                orientation = <2>;

                port {
                    cam_endpoint: endpoint {
                        clock-lanes = <0>;
                        data-lanes = <1 2 3 4>;
                        clock-continuous;
                        link-frequencies =
                            /bits/ 64 <100000000>;
                    };
                };
            };
        };
    };

    csi_frag: fragment@101 {
        target = <&csi1>;
        csi: __overlay__ {
            status = "okay";
            brcm,media-controller;

            port {
                csi_ep: endpoint {
                    remote-endpoint = <&cam_endpoint>;
                    clock-lanes = <0>;
                    data-lanes = <1 2 3 4>;
                    clock-continuous;
                };
            };
        };
    };

    __overrides__ {
        rotation = <&cam_node>,"rotation:0";
        orientation = <&cam_node>,"orientation:0";
        media-controller = <&csi>,"brcm,media-controller?";
        cam0 = <&i2c_frag>, "target:0=",<&i2c_csi_dsi0>,
               <&csi_frag>, "target:0=",<&csi0>,
               <&cam_node>, "VIN-supply:0=",<&cam0_reg>;
    };
};

&cam_node {
    status = "okay";
};

&cam_endpoint {
    remote-endpoint = <&csi_ep>;
};

Still loads my driver on I²C #4 (i2c_csi_dsi1) instead of I²C #6 (i2c_csi_dsi0) when option cam0 is passed to the dtoverlay. If I change i2c_frag@100 to target = <&i2c_csi_dsi0>; straight away, then right I²C is used.

Expected behaviour Bring back previous behaviour and change the target properly.

Actual behaviour While the messages show 3 overrides applied, driver is still probed on I²C #4. I tried to analyse the DTB produced, but I'm not that well versed to understand the hexadecimals put if dtc -I dtb ... -O dts is used on these byproducts of dtoverlay command.

System raspinfo content

Logs Included in above.

Additional context The worst part is I got hit by this by surprise and started to think my RPi is broken.

[pelwell]

I'm guessing this is on a Pi 5? You should really say.

Is this using the dtoverlay command or config.txt setting? You should really say.

It's working for me as expected, both with the config.txt setting and the runtime command. Using the above overlay with the cam0 parameter, run this command and attach the dts.zip file:

dtc -I fs -O dts /proc/device-tree 2>/dev/null | zip dts.zip -

[michalfita]

I'm guessing this is on a Pi 5? You should really say.

Not in pastebin data?

Is this using the dtoverlay command or config.txt setting? You should really say.

It's using dtoverlay command, what's mentioned in the actual behaviour section.

It's working for me as expected

~It was. But stopped.~ Now I wonder if kernel may be a culprit.

It's not funny at all, after you messaged me it started to work again. I'll go back with the ZIP when it stops working again.