Re: ipu-bridge: software nodes are never unregistered; PCI remove/rescan of IPU6 fails with -EEXIST and leaves dangling properties

[D. Manresa]

[Resending with the lists on Cc - the first copy of this reply went out
to the people only, due to the same mail tooling error on my side that
Hans just caught on the int3472 patch. Fixed now; apologies for the
duplicate, Sakari and Hans.]

On Sun, 31 Aug 2026, Sakari Ailus wrote:
> I recall unbinding the ipu6 driver successfully in the past. Do you ensure
> above all sub-device drivers have been unbound first? I guess the V4L2
> framework nor the ipu6 driver necessarily ensure that right now.

Measured it, since the machine reproduces this in a minute: unbinding all
three sensor sub-device drivers first (ov5693, ov8865, ov7251 - each
confirmed unbound via sysfs; the VCM client had no driver bound) and then
running the same PCI remove -> module unload -> rescan -> modprobe sequence
fails identically, byte for byte:

  sysfs: cannot create duplicate filename '/kernel/software_nodes/INT343E'
   software_node_register+0xd2/0x120
   ipu_bridge_init+0x192/0xeb0 [ipu_bridge]
   ipu6_pci_probe+0x417/0xbe0 [intel_ipu6]
  kobject: kobject_add_internal failed for INT343E with -EEXIST, ...
  intel-ipu6 0000:00:05.0: error -EEXIST: IPU6 bridge init failed

Which makes sense: unbinding the sensors neither unregisters the bridge's
software nodes nor clears their ACPI fwnode->secondary pointers, and the
-EEXIST happens at the IPU HID node registration, before any per-sensor code
runs. A plain module unload/reload without the PCI remove does work, as you
say - the device keeps its secondary fwnode, so the graph is still wired -
but any path that goes through device_del() (which clears the secondary via
set_primary_fwnode(dev, NULL)) ends at the -EEXIST.

While re-testing this I also got a clean confirmation of the dangling
link-frequencies: with the creator module unloaded, rebinding ov5693 against
the surviving nodes fails with "supported link freq 419200000ll not found"
(-22), and the same rebind succeeds the moment the module is loaded again -
identical rodata back at the same address under the stale pointer.

Hans: thanks for the quick ack on the split. Series sent as

  [PATCH 0/2] media: ipu-bridge: survive module unload and reuse the
  software nodes on rebind

threaded to this report - with one correction to my point 2a folded into the
commit message of 1/2: the property *name* strings in prop_names were never a
problem (char arrays, already copied); the real module-image references were
the link-frequencies values and the "lens-focus" property name literal.

D. Manresa <dmanresa@xxxxxxxxx>