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

[Sakari Ailus]

Hi Hans, D.,

On Sun, Aug 30, 2026 at 02:40:52PM +0200, johannes.goede@xxxxxxxxxxxxxxxx wrote:
> Hi,
> 
> On 28-Aug-26 22:54, D. Manresa wrote:
> > Hi Sakari,
> > 
> > On Fri, Aug 28, 2026 at 06:33:16PM +0300, Sakari Ailus wrote:
> >> The regulator string length has been increased to 6 since and I believe
> >> with <20260729-sp7plus-int3472-v2-1-cdfaf97ac3ad@xxxxxxx> (on LMML) the
> >> camera might work streaming-wise at least. There might be Bayer order
> >> issues though, there was another patchset
> >> (<20260729-sp7plus-ov-flips-v2-0-91884b81a8f5@xxxxxxx>) addressing those.
> > 
> > Thanks for the pointers -- good to know about the string length fix, and
> > we are aware of Jakob's two series: we have adopted his POWER1 approach
> > in our local tree and have offered him Tested-by on this hardware to
> > help both series move.
> > 
> > This report is orthogonal to the sensor bring-up, though: all three
> > sensors here are fully powered and streaming (the cameras work
> > end-to-end, hardware ISP included). The issue is that ipu-bridge has no
> > teardown -- after any unbind of the IPU PCI device its software nodes
> > stay registered, so a rescan can never re-probe (-EEXIST), and once the
> > module is gone the node properties dangle into freed module memory. It
> > reproduces on any ipu-bridge machine regardless of sensor state.
> > 
> > Would a fix be welcome, and if so, which direction do you prefer:
> > a real teardown on unbind (unregister the node groups, clear the
> > secondary fwnodes, drop the deliberate struct leak), or making
> > ipu_bridge_init() idempotent so a rebind reuses the already-registered
> > nodes? Happy to write and test either on this hardware.
> 
> Not Sakari, but IIRC the goal has always been for the nodes to
> stick around (be leaked) since other drivers may still reference
> them when the module goes away and then a rebind should use
> the already-registered nodes,
> 
> Which is why all of the swnodes are dynamically allocated and e.g.
> strings a strdup-ed and things are never freed. If there are pointers
> in the swnodes to things which go away on module unload then that is
> a bug which should fixed.

Indeed. Software nodes do support refcounting so in principle it should be
possible to remove the software nodes, given no driver is holding a
reference to them.

Software nodes, like OF and ACPI nodes, can reference other nodes and this
is the case with the graph data structure. As the remote-endpoint
properties refer to the other nodes, there should be a circular dependency
there, and current framework implementation really doesn't allow removing
the other node, whether or not a reference to the remote node is actually
acquired right now.

-- 
Kind regards,

Sakari Ailus