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 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.