[PATCH] media: ipu-bridge: Add upside-down sensor quirks for the Surface Pro 9

[Fernando Rimoli <fernandorimoli11@gmail.com>]

The Microsoft Surface Pro 9 mounts both its front sensor (OVTI5693) and
its rear one (OVTID858) rotated 180 degrees, and its SSDB reports 0 for
each, so frames from either arrive inverted with nothing to say so.

Add both to upside_down_sensor_dmi_ids. The two entries carry identical
DMI matches and differ only in the ACPI HID they gate on, which works
because ipu_bridge_parse_rotation() walks every matching DMI entry rather
than stopping at the first one.

Measured on a Surface Pro 9, DMI product SKU Surface_Pro_9_2038, IPU6
Alder Lake-P 8086:465d, where the inversion of both sensors was confirmed
visually. Matched on DMI_PRODUCT_NAME as the rest of the table is, rather
than on the narrower SKU: the entries only take effect when the ACPI HID
matches too, so a variant of the same model that shipped different
sensors is left alone.

This makes the kernel report the mounting truthfully and does no more
than that. Nothing in the bridge rotates pixels, so an application that
reads the property can turn the image the right way up while one that
ignores it still shows it inverted.

Signed-off-by: Fernando Rimoli <fernandorimoli11@gmail.com>
---
Applies to media/next as it stands today.

Two notes for whoever sequences this against Sergey Lebedev's Surface Pro 11
entry, which is in flight for the same table:

  https://lore.kernel.org/linux-media/20260913153526.80287-1-lsa.uz@pm.me/

Both his entry and mine go in immediately before the terminating entry, so
whichever is applied second needs a one-line context fix. Nothing else in the
two overlaps: different machines, different HIDs.

Separately, and only because it would be a shame for it to be dropped
silently: his version as posted does not apply to the current tip. Its hunk
context ends at the Samsung Galaxy Book5 Pro 360 entry (OVTI02E1), while the
table now ends with the Book3 Ultra (960XFH, OVTI02C1), so his base predates
that entry. A rebase is all it needs.

I have not touched the Surface Pro 9 rear sensor's own bridge entry here.
That is Sergey's patch, which I tested separately:

  https://lore.kernel.org/linux-media/20260913142034.5632-1-lsa.uz@pm.me/

 drivers/media/pci/intel/ipu-bridge.c | 16 ++++++++++++++++
 1 file changed, 16 insertions(+)

diff --git a/drivers/media/pci/intel/ipu-bridge.c b/drivers/media/pci/intel/ipu-bridge.c
index 952868a..f286881 100644
--- a/drivers/media/pci/intel/ipu-bridge.c
+++ b/drivers/media/pci/intel/ipu-bridge.c
@@ -226,6 +226,22 @@ static const struct dmi_system_id upside_down_sensor_dmi_ids[] = {
 		},
 		.driver_data = "OVTI02C1",
 	},
+	{
+		/* Microsoft Surface Pro 9, front sensor */
+		.matches = {
+			DMI_EXACT_MATCH(DMI_SYS_VENDOR, "Microsoft Corporation"),
+			DMI_EXACT_MATCH(DMI_PRODUCT_NAME, "Surface Pro 9"),
+		},
+		.driver_data = "OVTI5693",
+	},
+	{
+		/* Microsoft Surface Pro 9, rear sensor */
+		.matches = {
+			DMI_EXACT_MATCH(DMI_SYS_VENDOR, "Microsoft Corporation"),
+			DMI_EXACT_MATCH(DMI_PRODUCT_NAME, "Surface Pro 9"),
+		},
+		.driver_data = "OVTID858",
+	},
 	{} /* Terminating entry */
 };