sensor: label vendor by part number, not by which probe matched

[widgetii]

Problem

detect_superpix_sensor() doesn't probe a vendor — it probes a register family: 0xFD-paged 8-bit registers with the id at 0x02/0x03. Since the 2018-19 WillSemi acquisitions, OmniVision and SuperPix are the same group and ship that design under both SP and OV/OS part numbers, so this one probe matches parts from two brands.

get_sensor_id_i2c() nevertheless stamped every hit SuperPix, because the label was attached to the probe rather than to the id it matched. Five of the eight ids the function recognises are OmniVision part numbers:

id	model printed	brand that owns the number
0x140a	SP140a	SuperPix
0x2735	OV2735	OmniVision
0x4308	OS04B10	OmniVision
0x5302	SP2308 (or OS02M10)	SuperPix / ambiguous
0x5303	OS03B10	OmniVision
0x5602	OS02G10	OmniVision
0x530444	OS04D10	OmniVision
0xfa/0xfb path	SP2305	SuperPix

so ipctool emitted self-contradictory output:

sensor:
  vendor: SuperPix
  model: OS04B10

That YAML is what ipctool upload ships to the OpenIPC cloud, so every affected camera contributed a wrong vendor/model pairing to the collected hardware data.

The OS04D10 case already knew about this — it carried // Need to overwrite vendor somehow or move this to OV detect function with a commented-out strcpy(ctx->vendor, "OmniVision"), which could not work while the caller overwrote the field afterwards.

Fix

Set the vendor per matched id, inside the probe, and stop the caller from overriding it. The rule is the brand that owns the part number we print: SP numbers → SuperPix, OV/OS numbers → OmniVision. That's the only assignment which keeps the two emitted fields consistent with each other.

Scope / risk

• Model strings are unchanged. Whether 0x2735 should print OV2735 or SP2305 is a separate question — see fix SP2305 detection #180; the two are the same die and the id cannot distinguish them.
• Output-only. Nothing consumes the sensor vendor programmatically: getsensoridentity() returns model_control, getsensorshort() returns the model alone, and ipcinfo -v is the chip vendor. Firmware sensor-loading scripts (load_hisilicon, load_goke) switch on ipcinfo --short-sensor, which this doesn't touch.
• Builds clean; formatting checked by the pre-commit clang-format hook.

Testing

Compile-tested only — I don't have any of the affected sensors to hand. Anyone with an OS04B10 / OS02G10 / OS03B10 / OS04D10 / OV2735 board: ipctool should now report the matching OmniVision vendor instead of SuperPix.

[qodo-free-for-open-source-projects]

PR Summary by Qodo

Fix sensor vendor labeling to follow matched part number (SP vs OV/OS)

🐞 Bug fix 🕐 10-20 Minutes

AI Description

• Set sensor vendor based on the matched sensor ID, not the probe name.
• Prevent get_sensor_id_i2c() from overwriting vendor for SuperPix-family probes.
• Fix inconsistent vendor/model pairs in ipctool output and uploaded inventory data.

Diagram

graph TD
  A["get_sensor_id_i2c()"] --> B["detect_possible_sensors()"] --> C["detect_superpix_sensor()"] --> D{{"FD-paged sensor"}}
  C --> E["Set ctx.vendor (by id)"] --> F["Set ctx.sensor_id"]

Loading

High-Level Assessment

The following are alternative approaches to this PR:

1. Table-driven ID mapping (id → vendor/model)

• ➕ Reduces switch-case duplication and makes vendor/model coupling explicit
• ➕ Easier to audit/extend as more IDs are added
• ➖ Slightly more refactor than necessary for a targeted fix
• ➖ May require careful handling for the res vs res2 (24-bit) ID path

2. Split WillSemi paged-family detection into a neutral probe

• ➕ Makes it clearer this probe is for a register family, not a vendor
• ➕ Could return a structured result (vendor enum + model) to avoid string writes
• ➖ Larger signature/flow change across detection plumbing
• ➖ Not needed to resolve the immediate mislabeling bug

Recommendation: The PR’s approach is the best minimal fix: assign vendor inside detect_superpix_sensor() per matched part number and stop the caller from clobbering it. A table-driven mapping is a reasonable follow-up refactor if IDs continue to grow, but it is not required to correct the vendor/model inconsistency.

Files changed (1) +18 / -6

Bug fix (1) +18 / -6

sensors.cSet vendor per matched SuperPix-family sensor ID; avoid caller override +18/-6

Set vendor per matched SuperPix-family sensor ID; avoid caller override

• Moves vendor assignment into detect_superpix_sensor() for each recognized ID (SP vs OV/OS) and sets OmniVision for the OS04D10 (0x530444) 24-bit ID path. Updates get_sensor_id_i2c() to no longer overwrite ctx->vendor after this probe, preserving the ID-derived vendor/model consistency in ipctool output.

src/sensors.c

[qodo-free-for-open-source-projects]

Code Review by Qodo

🐞 Bugs (0) 📘 Rule violations (0) 📎 Requirement gaps (0)

Great, no issues found!

Qodo reviewed your code and found no material issues that require review

_{To customize comments, go to the Qodo configuration screen, or learn more in the docs.}