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 2/2] media: ipu-bridge: reuse the software nodes on rebind
Date: Mon, 26 Oct 2026 09:25:49 +0100 [thread overview]
Message-ID: <20261026082549.662885-3-dmanresa@gmail.com> (raw)
In-Reply-To: <20261026082549.662885-1-dmanresa@gmail.com>
The software nodes are deliberately never unregistered so that a rebind
can reuse them, but ipu_bridge_init() only takes that path when the IPU
kept its secondary fwnode link. Removing and re-scanning the IPU PCI
device clears that link, so the next probe tries to register the IPU HID
node again and fails:
sysfs: cannot create duplicate filename '/kernel/software_nodes/INT343E'
intel-ipu6 0000:00:05.0: Failed to register the IPU HID node
intel-ipu6: probe of 0000:00:05.0 failed with error -17
after which the cameras are unusable until reboot.
Look the registered node up instead and restore the device's secondary
fwnode, keeping the reference the lookup took. software_node_notify()
resolves a device's software node through its secondary fwnode, which is
not set yet when device_add() calls it, so it takes no reference, while
the device_del() of the next remove does resolve it and calls
swnode_put(). Dropping the lookup reference as well would cost the node
one reference per remove/rescan cycle: measured on a Surface Pro 7+, it
was gone from /sys/kernel/software_nodes by the fourth.
Assisted-by: LLM
Fixes: 803abec64ef9 ("media: ipu3-cio2: Add cio2-bridge to ipu3-cio2 driver")
Signed-off-by: D. Manresa <dmanresa@gmail.com>
---
drivers/media/pci/intel/ipu-bridge.c | 22 ++++++++++++++++++++++
1 file changed, 22 insertions(+)
diff --git a/drivers/media/pci/intel/ipu-bridge.c b/drivers/media/pci/intel/ipu-bridge.c
index aea4699..45a304c 100644
--- a/drivers/media/pci/intel/ipu-bridge.c
+++ b/drivers/media/pci/intel/ipu-bridge.c
@@ -1098,6 +1098,7 @@ static DEFINE_MUTEX(ipu_bridge_mutex);
int ipu_bridge_init(struct device *dev,
ipu_parse_sensor_fwnode_t parse_sensor_fwnode)
{
+ const struct software_node *ipu_node;
struct fwnode_handle *fwnode;
struct ipu_bridge *bridge;
unsigned int i;
@@ -1108,6 +1109,27 @@ int ipu_bridge_init(struct device *dev,
if (!ipu_bridge_check_fwnode_graph(dev_fwnode(dev)))
return 0;
+ /*
+ * The nodes registered by a previous bind are still there, but the
+ * PCI remove/rescan cycle dropped the IPU's secondary fwnode link to
+ * them. Registering them again would fail with -EEXIST, so reuse
+ * them and restore just that link.
+ */
+ ipu_node = software_node_find_by_name(NULL, IPU_HID);
+ if (ipu_node) {
+ fwnode = software_node_fwnode(ipu_node);
+ /*
+ * The node only becomes the device's secondary fwnode here,
+ * after device_add() has run, so software_node_notify() took
+ * no reference on it. Keep the one from the lookup for the
+ * swnode_put() that software_node_notify_remove() will do on
+ * the next device_del().
+ */
+ set_secondary_fwnode(dev, fwnode);
+ dev_dbg(dev, "Reusing the previously registered software nodes\n");
+ return 0;
+ }
+
if (!ipu_bridge_ivsc_is_ready())
return dev_err_probe(dev, -EPROBE_DEFER,
"waiting for IVSC to become ready\n");
--
2.43.0
prev parent 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 [PATCH v5 0/2] media: ipu-bridge: survive module unload and " D. Manresa
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 ` D. Manresa [this message]
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-3-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®