[PATCH] media: ipu-bridge: Keep the clock-noncontinuous property name out of rodata

[Fernando Rimoli]

The software nodes ipu-bridge registers on a successful init are never
unregistered. There is no module_exit and no remove hook, and every
software_node_unregister_node_group() call sits on an error unwind label
inside ipu_bridge_init(), so on success the nodes stay registered and
readable after the module is unloaded, which a later rebind relies on.

Nothing reachable from a registered node may therefore point into the
module image. PROPERTY_ENTRY_BOOL() stores a pointer to its name, so the
"clock-noncontinuous" string literal leaves the surviving node carrying a
dangling property name once ipu-bridge is gone.

Add the name to struct ipu_property_names, which is copied by value into
each struct ipu_sensor, and use that copy, as every other endpoint
property name already does.

Fixes: 8e3def7bf410 ("media: ipu-bridge: Request non-continuous clock for ov5693 on IPU6")
Reported-by: D. Manresa <dmanresa@xxxxxxxxx>
Closes: https://lore.kernel.org/linux-media/20260905211307.542810-1-dmanresa@xxxxxxxxx/
Signed-off-by: Fernando Rimoli <fernandorimoli11@xxxxxxxxx>
---
The series is already in next, so this is a follow-up rather than a respin.

Two things below would both need 8e3def7bf410 itself to be amended. I do not
know whether you rebase that branch, so please treat them as questions, and 
just apply this patch as it stands if the answer is no.

1. This could be squashed into 8e3def7bf410 instead of landing on top of it.
   The bug has never been in a released kernel, so there is nothing for stable
   to pick up, and the Fixes: SHA above is from next and would not survive a
   rebase in any case. One correct commit seems better, but a separate
   commit is entirely fine by me.

   If you do squash it, please carry the Reported-by and Closes: across.

2. D. Manresa sent a tested tag for patches 4-7 on 2026-09-06, five days
   before the series was applied and it didn't reach the commits. It is in
   the thread here:

     https://lore.kernel.org/linux-media/20260906073932.24090-1-dmanresa@xxxxxxxxx/

   His is the only report that exercises the sensor's 2x2 binned readout
   through the IPU6 hardware ISP; the other four are all raw ISYS capture.

Neither is a reason to hold up the fix itself.

For anyone testing by swapping modules under CONFIG_MODVERSIONS: this grows
struct ipu_property_names, and therefore struct ipu_sensor, so the CRCs of
ipu_bridge_init() and ipu_bridge_parse_ssdb() move again. intel-ipu6 needs
rebuilding alongside ipu-bridge.
 drivers/media/pci/intel/ipu-bridge.c | 3 ++-
 include/media/ipu-bridge.h           | 1 +
 2 files changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/media/pci/intel/ipu-bridge.c b/drivers/media/pci/intel/ipu-bridge.c
index 952868a..233c513 100644
--- a/drivers/media/pci/intel/ipu-bridge.c
+++ b/drivers/media/pci/intel/ipu-bridge.c
@@ -237,6 +237,7 @@ static const struct ipu_property_names prop_names = {
 	.data_lanes = "data-lanes",
 	.remote_endpoint = "remote-endpoint",
 	.link_frequencies = "link-frequencies",
+	.clock_noncontinuous = "clock-noncontinuous",
 };
 
 static const char * const ipu_vcm_types[] = {
@@ -591,7 +592,7 @@ static void ipu_bridge_create_fwnode_properties(
 
 	if (cfg->flags & IPU_BR_FL_CSI2_CLK_NONCONTINUOUS)
 		sensor->ep_properties[IPU_BRIDGE_NEXT_PROPERTY(i, EP_CLOCK_NONCONTINUOUS)] =
-			PROPERTY_ENTRY_BOOL("clock-noncontinuous");
+			PROPERTY_ENTRY_BOOL(names->clock_noncontinuous);
 
 	sensor->ipu_properties[0] = PROPERTY_ENTRY_U32_ARRAY_LEN(
 					sensor->prop_names.data_lanes,
diff --git a/include/media/ipu-bridge.h b/include/media/ipu-bridge.h
index 760f076..3ef94c2 100644
--- a/include/media/ipu-bridge.h
+++ b/include/media/ipu-bridge.h
@@ -135,6 +135,7 @@ struct ipu_property_names {
 	char data_lanes[11];
 	char remote_endpoint[16];
 	char link_frequencies[17];
+	char clock_noncontinuous[20];
 };
 
 struct ipu_node_names {