From: Sakari Ailus <sakari.ailus@linux.intel.com>
To: "D. Manresa" <dmanresa@gmail.com>
Cc: Hans de Goede <johannes.goede@oss.qualcomm.com>,
Daniel Scally <dan.scally@ideasonboard.com>,
Mauro Carvalho Chehab <mchehab@kernel.org>,
linux-media@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 2/2] media: ipu-bridge: reuse the software nodes on rebind
Date: Mon, 31 Aug 2026 15:11:37 +0300 [thread overview]
Message-ID: <apVveTVtPTGZ15J7@kekkonen.localdomain> (raw)
In-Reply-To: <20260831094257.29398-3-dmanresa@gmail.com>
Hi D.,
On Mon, Aug 31, 2026 at 11:42:56AM +0200, D. Manresa wrote:
> The software nodes registered by ipu_bridge_init() are deliberately
> never unregistered, and the intended design is for a rebind to reuse
> the already registered nodes. That reuse path however only exists for
> the case where the IPU device kept its secondary fwnode link, which the
> fwnode graph check at the top of ipu_bridge_init() detects: then the
> function returns early. When the link is gone, ipu_bridge_init()
> unconditionally registers the IPU HID software node again, which fails
> with -EEXIST on the sysfs name (the node from the previous bind is
> still registered) and the IPU driver fails to probe.
>
> That is exactly what happens when the IPU PCI device is removed and
> re-scanned: device_del() unsets the ACPI companion, and
> set_primary_fwnode(dev, NULL) then clears the ACPI fwnode's ->secondary
> pointer, so the fwnode graph check on the next probe finds no endpoints
> and falls through to registration. Observed on a Surface Pro 7+ (IPU6):
>
> echo 1 > /sys/bus/pci/devices/0000:00:05.0/remove
> modprobe -r intel_ipu6_isys intel_ipu6 # ipu-bridge unloads too
> echo 1 > /sys/bus/pci/rescan
> modprobe intel_ipu6
>
> 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.
>
> Add the missing reuse path: if the IPU software node is already
> registered, look it up with software_node_find_by_name(), point the
> device's secondary fwnode at it and return success. Restoring the IPU's
> secondary fwnode is all a rebind needs: the sensors' ACPI fwnodes still
> carry their secondary fwnode pointers from the first bind (the sensor
> devices are not removed by an IPU unbind, so nothing clears those), and
> the IVSC and VCM links likewise live on devices that survive an IPU
> rebind. The previous commit made the registered nodes self-contained in
I'd refer to the patch by a name, but I don't think you really need that
reference here.
> the never freed bridge allocation, so their properties are still valid
> here. The IVSC readiness check is intentionally skipped on this path,
> as the IVSC links were already established by the first bind.
I'd say this is a bit too elaborate for a commit message. Please shorten
it.
>
> software_node_find_by_name() takes a reference on the node it returns;
> drop it right away since the node is kept alive by its never dropped
> registration, matching the reference handling of the initial-bind path.
>
> Developed with the assistance of an AI tool (Claude)
Please use Assisted-by: tag, see
Documentation/process/coding-assistants.rst .
>
> 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 | 24 ++++++++++++++++++++++++
> 1 file changed, 24 insertions(+)
>
> diff --git a/drivers/media/pci/intel/ipu-bridge.c b/drivers/media/pci/intel/ipu-bridge.c
> index 4de42ed..6fa1c3c 100644
> --- a/drivers/media/pci/intel/ipu-bridge.c
> +++ b/drivers/media/pci/intel/ipu-bridge.c
> @@ -930,6 +930,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;
> @@ -940,6 +941,29 @@ int ipu_bridge_init(struct device *dev,
> if (!ipu_bridge_check_fwnode_graph(dev_fwnode(dev)))
> return 0;
>
> + /*
> + * The software nodes registered by a previous ipu_bridge_init() call
> + * are deliberately kept registered when the module is unloaded, and
> + * the sensors' ACPI fwnodes still have them as their secondary
> + * fwnodes. If the IPU software node is already registered this is a
> + * rebind, e.g. after the PCI device was removed and re-scanned,
> + * which drops the IPU's secondary fwnode link. Registering the nodes
> + * again would fail with -EEXIST, so instead reuse them and just
> + * restore the IPU's secondary fwnode link.
> + */
> + ipu_node = software_node_find_by_name(NULL, IPU_HID);
> + if (ipu_node) {
> + fwnode = software_node_fwnode(ipu_node);
> + set_secondary_fwnode(dev, fwnode);
> + /*
> + * The node stays registered, it does not need the reference
> + * software_node_find_by_name() took to stay alive.
> + */
> + fwnode_handle_put(fwnode);
> + dev_info(dev, "Reusing the previously registered software nodes\n");
I think dev_dbg() should suffice here.
> + return 0;
> + }
> +
> if (!ipu_bridge_ivsc_is_ready())
> return dev_err_probe(dev, -EPROBE_DEFER,
> "waiting for IVSC to become ready\n");
--
Regards,
Sakari Ailus
next prev parent reply other threads:[~2026-08-31 12:12 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 ` [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 [this message]
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=apVveTVtPTGZ15J7@kekkonen.localdomain \
--to=sakari.ailus@linux.intel.com \
--cc=dan.scally@ideasonboard.com \
--cc=dmanresa@gmail.com \
--cc=johannes.goede@oss.qualcomm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-media@vger.kernel.org \
--cc=mchehab@kernel.org \
/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