From: "D. Manresa" <dmanresa@gmail.com>
To: sakari.ailus@linux.intel.com, johannes.goede@oss.qualcomm.com,
dan.scally@ideasonboard.com
Cc: mchehab@kernel.org, fernandorimoli11@gmail.com, lsa.uz@pm.me,
linux-media@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: [PATCH v5 0/2] media: ipu-bridge: survive module unload and reuse the software nodes on rebind
Date: Mon, 26 Oct 2026 09:25:47 +0100 [thread overview]
Message-ID: <20261026082549.662885-1-dmanresa@gmail.com> (raw)
Hello,
v5 fixes a reference counting bug that 2/2 had in v4, and carries
Fernando Rimoli's Tested-by on 1/2.
A correction before anything else: in v4 I wrote that the Surface Pro 7+
was leaving my hands and that the patches were compile-tested only. It
is still here for a few more days, so this version is tested on it.
2/2 as posted in v4 dropped the reference software_node_find_by_name()
takes, on the grounds that the node is never unregistered. That is the
wrong half of the story. software_node_notify() resolves a device's
software node through dev_fwnode(dev)->secondary, which the IPU does not
have yet when device_add() calls it, so it takes no reference;
software_node_notify_remove() does resolve it on the next device_del()
and calls swnode_put(). The reuse path has to hand its reference to that
put.
Measured on the Pro 7+ with a module that reads the kobject reference
count of the INT343E node directly:
v4 2/2 as posted 4 -> 3 -> 2 -> 1, and the node is gone from
/sys/kernel/software_nodes on the fourth
remove/rescan cycle. Reproduced twice.
v5 2/2 4 -> 3 on each PCI remove, back to 4 on each
bind, over 16 cycles, children intact.
The decrement happens at the PCI remove, not at the module unload, and
only the IPU node is affected: the sensors' own nodes (INT33BE-4,
INT347A-1, INT347E-5 here) hold steady, since those devices are never
deleted. A remove that follows a failed bind costs nothing, because
there is no secondary fwnode left for software_node_notify_remove() to
resolve.
The series itself, on a Surface Pro 7+ (IPU6 Tiger Lake, 8086:9a19 at
0000:00:05.0, OV5693 + OV8865 + OV7251) running 6.19 with the equivalent
change:
- without the series, the PCI remove -> modprobe -r -> rescan ->
modprobe sequence fails exactly as the 2/2 commit message describes,
with -EEXIST, and the cameras stay dead until a reboot;
- with it, four cycles complete and all three sensors stream after
each one.
Two things that cost me time, in case they would cost a reviewer the
same:
- modprobe -r intel_ipu6_isys intel_ipu6 leaves ipu_bridge resident at
reference count 0. Without an explicit modprobe -r ipu_bridge the
module image is never freed and neither failure reproduces.
- the reuse path logs at dev_dbg(), so it is invisible without
dyndbg=+p.
The asymmetry underneath this is in drivers/base, not here: a software
node that becomes a device's secondary fwnode after device_add() gets a
swnode_put() at device_del() that no swnode_get() ever matched. I am
accounting for it in the bridge because that is where this series is,
but if it should be balanced in software_node_notify() instead, say so
and I will send that.
Unrelated but worth flagging: Sergey Lebedev's "Add the Surface Pro 11
infrared illuminator" series touches the same two lines 1/2 does
(dev_properties[3] and the "lens-focus" name), so whichever of the two
lands second needs a trivial rebase.
Changes since v4:
- 2/2: keep the reference from software_node_find_by_name() instead of
dropping it, and say in the comment what consumes it;
- 2/2: commit message notes the reference counting;
- 1/2: Fernando Rimoli's Tested-by (Surface Pro 9);
- tested on hardware, where v4 was compile-tested only.
Changes since v3:
- 1/2 and 2/2: commit messages cut down;
- 1/2: lens_focus moved into struct ipu_property_names and link_freqs
into struct ipu_sensor;
- 2/2: reuse-path comment shortened.
v4: https://lore.kernel.org/linux-media/20261010155626.2766298-1-dmanresa@gmail.com/
v3: https://lore.kernel.org/linux-media/20261008132614.2456716-1-dmanresa@gmail.com/
Thanks,
D. Manresa
D. Manresa (2):
media: ipu-bridge: don't reference the module image from software
nodes
media: ipu-bridge: reuse the software nodes on rebind
drivers/media/pci/intel/ipu-bridge.c | 34 +++++++++++++++++++++++++++++++---
include/media/ipu-bridge.h | 6 ++++++
2 files changed, 37 insertions(+), 3 deletions(-)
--
2.43.0
next reply other threads:[~2026-10-26 8:25 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-26 8:25 D. Manresa [this message]
2026-10-26 8:25 ` [PATCH v5 1/2] media: ipu-bridge: don't reference the module image from software nodes D. Manresa
2026-10-26 8:25 ` [PATCH v5 2/2] media: ipu-bridge: reuse the software nodes on rebind 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=20261026082549.662885-1-dmanresa@gmail.com \
--to=dmanresa@gmail.com \
--cc=dan.scally@ideasonboard.com \
--cc=fernandorimoli11@gmail.com \
--cc=johannes.goede@oss.qualcomm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-media@vger.kernel.org \
--cc=lsa.uz@pm.me \
--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
all inboxes | Powered by JetHome®