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.