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

[Sakari Ailus]

Hi D.,

On Mon, Aug 31, 2026 at 12:23:28PM +0200, D. Manresa wrote:
> [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

In fact the sub-device drivers aren't meant to go anywhere whilst the
sub-devices remain registered.

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

Indeed.

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

-- 
Regards,

Sakari Ailus