Re: [PATCH v4 1/2] media: ipu-bridge: don't reference the module image from software nodes

[Fernando Rimoli <fernandorimoli11@gmail.com>]

Hi,

You said the Surface Pro 7+ is leaving your hands, so here is a run on
other hardware: a Surface Pro 9, IPU6 Alder Lake-P (8086:465d), with
three sensors on the bridge (OVTI5693, OVTID858, SMO55F0).

To be clear, both of the failures you fixed need the IPU driver
unloaded, by module unload or by PCI remove and rescan, and I cannot do
that on this machine. A warm reload of intel-ipu6 leaves its CSE
firmware refusing authentication, and the cameras stay dead until a cold
boot. So this is a no-regression run of the normal paths, not a
reproduction of the bug.

What I ran: your v4 1/2 and 2/2 on the 6.19-based tree this machine
boots, on top of a20c843c9bc4 ("media: ipu-bridge: Keep the
clock-noncontinuous property name out of rodata"), which your 1/2 builds
on. Both applied with offsets only. 1/2 changes struct ipu_sensor, so I
rebuilt intel-ipu6 against the new header as well. intel-ipu6-isys was
not rebuilt, and all 24 symbols it imports still match.

After a cold boot:

  intel-ipu6 0000:00:05.0: Found supported sensor OVTI5693:00
  intel-ipu6 0000:00:05.0: Found supported sensor OVTID858:00
  intel-ipu6 0000:00:05.0: Found supported sensor SMO55F0:00
  intel-ipu6 0000:00:05.0: Connected 3 cameras

The two sensors whose drivers parse link-frequencies from the endpoint
get it from the per-sensor copy:

  ov5693   419200000
  vd55g    396000000

(ov13858 never parses the property; it reports its own menu, 540000000.)
Unbinding and rebinding those two sensor drivers, three times in all,
parses the same nodes again, and the values come back intact each time.
The front sensor needs clock-noncontinuous on this machine (without it,
it delivers no frames), and it streams at 28.63 fps, so the per-sensor
property names reach it too. Rear 29.94 fps, unchanged. No warnings in
the log from the bridge.

Tested-by: Fernando Rimoli <fernandorimoli11@gmail.com> # Surface Pro 9, IPU6 (8086:465d); boot and sensor rebind, not unload or rescan

I have not put a tag on 2/2. Its new path only runs when the IPU node is
already registered at init, which never happens on a normal boot, so
nothing I could run here reaches it.

Fernando