From: johannes.goede@oss.qualcomm.com
To: "D. Manresa" <dmanresa@gmail.com>,
Sakari Ailus <sakari.ailus@linux.intel.com>
Cc: Dan Scally <dan.scally@ideasonboard.com>,
Mauro Carvalho Chehab <mchehab@kernel.org>,
linux-media@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: ipu-bridge: software nodes are never unregistered; PCI remove/rescan of IPU6 fails with -EEXIST and leaves dangling properties
Date: Sun, 30 Aug 2026 14:40:52 +0200 [thread overview]
Message-ID: <096b57f0-90be-406d-bcbb-74d19dee91a5@oss.qualcomm.com> (raw)
In-Reply-To: <20260828205424.154443-1-dmanresa@gmail.com>
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@berg.pm> (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@berg.pm>) 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.
Regards,
Hans
next prev parent reply other threads:[~2026-08-30 12:40 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-27 23:26 ipu-bridge: software nodes are never unregistered; PCI remove/rescan of IPU6 fails with -EEXIST and leaves dangling properties D. Manresa
2026-08-28 15:33 ` Sakari Ailus
2026-08-28 20:54 ` D. Manresa
2026-08-30 12:40 ` johannes.goede [this message]
2026-08-31 8:02 ` Sakari Ailus
2026-08-31 10:23 ` D. Manresa
2026-08-31 11:36 ` Sakari Ailus
2026-08-31 9:03 ` Sakari Ailus
2026-08-31 9:42 ` [PATCH 0/2] media: ipu-bridge: survive module unload and reuse the software nodes on rebind D. Manresa
2026-08-31 9:42 ` [PATCH 1/2] media: ipu-bridge: don't reference the module image from software nodes D. Manresa
2026-08-31 9:42 ` [PATCH 2/2] media: ipu-bridge: reuse the software nodes on rebind D. Manresa
2026-08-31 12:11 ` Sakari Ailus
2026-08-31 14:03 ` [PATCH v2 0/2] media: ipu-bridge: survive module unload and " D. Manresa
2026-08-31 14:03 ` [PATCH v2 1/2] media: ipu-bridge: don't reference the module image from software nodes D. Manresa
2026-08-31 14:03 ` [PATCH v2 2/2] media: ipu-bridge: reuse the software nodes on rebind D. Manresa
2026-09-01 10:47 ` Sakari Ailus
2026-09-01 11:25 ` D. Manresa
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=096b57f0-90be-406d-bcbb-74d19dee91a5@oss.qualcomm.com \
--to=johannes.goede@oss.qualcomm.com \
--cc=dan.scally@ideasonboard.com \
--cc=dmanresa@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-media@vger.kernel.org \
--cc=mchehab@kernel.org \
--cc=sakari.ailus@linux.intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox