From: "D. Manresa" <dmanresa@gmail.com>
To: Sakari Ailus <sakari.ailus@linux.intel.com>,
Hans de Goede <johannes.goede@oss.qualcomm.com>,
Daniel Scally <dan.scally@ideasonboard.com>
Cc: Mauro Carvalho Chehab <mchehab@kernel.org>,
linux-media@vger.kernel.org, linux-kernel@vger.kernel.org,
"D . Manresa" <dmanresa@gmail.com>
Subject: [PATCH 0/2] media: ipu-bridge: survive module unload and reuse the software nodes on rebind
Date: Mon, 31 Aug 2026 11:42:54 +0200 [thread overview]
Message-ID: <20260831094257.29398-1-dmanresa@gmail.com> (raw)
In-Reply-To: <20260827232636.93145-1-dmanresa@gmail.com>
Hello,
This implements what was agreed in the "ipu-bridge: software nodes are
never unregistered" thread [1]: the software nodes are deliberately
leaked and cannot be removed (circular remote-endpoint references), so
instead of a teardown, make the two halves of the intended design work -
the nodes must actually survive module unload, and a rebind must reuse
them instead of failing.
[1/2] makes the registered properties self-contained in the never-freed
bridge allocation. One correction to my original report: the property
name strings I pointed at (prop_names) were never a problem - struct
ipu_property_names holds char arrays, so those are already copied. The
real module-image references were the "link-frequencies" property
values (pointing into the ipu_supported_sensors[] rodata) and the
"lens-focus" property name string literal. The link-frequencies one is
directly observable on hardware: with the creator module unloaded, a
re-probing sensor reads poisoned frequencies ("supported link freq
419200000ll not found"); reloading the module - which puts identical
rodata back at the same address - makes the same probe succeed again.
[2/2] adds the reuse path to ipu_bridge_init(): if the IPU HID node is
already registered, point the IPU's secondary fwnode at it and return.
The sensors' ACPI fwnodes keep their secondary pointers from the first
bind (nothing clears them), and with [1/2] the nodes they point at are
still valid.
Tested on a Surface Pro 7+ (IPU6 Tiger Lake, OV5693 + OV8865 + OV7251):
the PCI remove -> module unload -> rescan -> modprobe sequence from the
report, which today is fatal until reboot (-EEXIST), completes cleanly
with this series - "Reusing the previously registered software nodes" -
twice in a row, with all three cameras streaming after each rebind. Also
re-verified per Sakari's question that the failure is identical when all
sensor sub-device drivers are unbound before the PCI remove (answered
with the data in [1]).
The series was developed with the assistance of an AI tool (Claude) and
verified on the hardware described above.
Thanks,
D. Manresa
D. Manresa (2):
media: ipu-bridge: don't reference the module image from the software
nodes
media: ipu-bridge: reuse the software nodes on rebind
drivers/media/pci/intel/ipu-bridge.c | 38 ++++++++++++++++++++++++++---
include/media/ipu-bridge.h | 9 +++++++++
2 files changed, 44 insertions(+), 3 deletions(-)
--
2.43.0
next prev parent reply other threads:[~2026-08-31 9:43 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
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 ` D. Manresa [this message]
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=20260831094257.29398-1-dmanresa@gmail.com \
--to=dmanresa@gmail.com \
--cc=dan.scally@ideasonboard.com \
--cc=johannes.goede@oss.qualcomm.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