From: "D. Manresa" <dmanresa@gmail.com>
To: Sakari Ailus <sakari.ailus@linux.intel.com>
Cc: "D . Manresa" <dmanresa@gmail.com>,
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: Fri, 28 Aug 2026 22:54:24 +0200 [thread overview]
Message-ID: <20260828205424.154443-1-dmanresa@gmail.com> (raw)
In-Reply-To: <apGqPKMIk5kgqfMj@kekkonen.localdomain>
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.
Regards,
D. Manresa
next prev parent reply other threads:[~2026-08-28 20:54 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 [this message]
2026-08-30 12:40 ` johannes.goede
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=20260828205424.154443-1-dmanresa@gmail.com \
--to=dmanresa@gmail.com \
--cc=dan.scally@ideasonboard.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.