[openipc-ai]

The SC1135 has no ID in 0x3107/0x3108, so the SmartSens probe gave up on it ("SC1135 catches here") and the camera reported no sensor. It is told by 0x3008 = 0x60 and 0x3005 = 0x22: that is the pair the Xiongmai XM510 isp daemon accepts as an SC1135 once 0x3107/0x3108 matched none of its IDs. Under emulation (qemu-bench's xm510 machine with its generic xm-sensor), every 0x3005 value was tried with 0x3008 = 0x60 and the daemon accepted 0x22 alone, logging "SC1135 sensor init OK"; the open XM510 ISP in OpenIPC/openxiongmai carries that sensor's scripts.

The check runs only where 0x3107/0x3108 read 0x0000 or 0xffff, after the SOI, onsemi, OmniVision and Sony probes: those reads are 16-bit addressed, which an 8-bit device takes as a register write, so nothing identified or reported today sees an extra transaction. sensors_test gets a smartsens-sc1135 path; the fingerprint gains one line, 6022 SC1135, and nothing else changes.

Tested in the same emulator: SC1135 registers give SmartSens SC1135, 0x3005 = 0x23 gives no sensor, SC1235 registers still give SC1235. On two real XM510 cameras the JX-H62 and the AR0130 are unchanged. Not tested on SC1135 hardware.

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

PR Summary by Qodo

Detect SmartSens SC1135 using its fallback register signature

🐞 Bug fix 🕐 10-20 Minutes

AI Description

• Detect SC1135 when its primary ID registers do not identify a known SmartSens sensor.
• Preserve existing sensor matches and reporting of unexpected SmartSens IDs.

Diagram

graph TD
  Probe["SmartSens probe"] --> Primary["Primary ID read"] --> Known{"Known ID?"} -->|Yes| Existing["Existing model"] --> Identified["Sensor identified"]
  Known -->|No| Fallback{"SC1135 signature?"} -->|Yes| Identified
  Fallback -->|No| Undetected["No SmartSens match"]

Loading

High-Level Assessment

Keeping the signature check inside the SmartSens probe, after its known-ID cases, is appropriate: it adds SC1135 detection without changing earlier successful matches. Restricting the check to empty primary IDs would be narrower but would not follow the described ISP detection behavior.

Files changed (1) +15 / -7

Bug fix (1) +15 / -7

sensors.cAdd fallback SC1135 identification to the SmartSens probe +15/-7

Add fallback SC1135 identification to the SmartSens probe

• Checks registers 0x3008 and 0x3005 for the SC1135 signature when the primary SmartSens ID is unrecognized. Existing model matches remain unchanged, and unexpected nonempty primary IDs are still reported if the fallback does not match.

src/sensors.c

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

Code Review by Qodo

🐞 Bugs (1) 📘 Rule violations (0) 📎 Requirement gaps (0) 🎨 UX issues (0) 🔗 Cross-repo conflicts (0) 📜 Skill insights (0)

1. SC1135 detection can regress unnoticed ✓ Resolved

Description

is_smartsens_sc1135 adds a new positive identification path for the 0x3008/0x3005 register
pair, but the sensor probe fingerprint scenarios do not script or verify those registers. Future
changes can therefore break SC1135 recognition without a sensor-extraction regression test detecting
it.

Code

src/sensors.c[R475-477]

+static bool is_smartsens_sc1135(int fd, unsigned char i2c_addr) {
+    return i2c_read_register(fd, i2c_addr, 0x3008, 2, 1) == 0x60 &&
+           i2c_read_register(fd, i2c_addr, 0x3005, 2, 1) == 0x22;

Evidence

The PR adds a new register-pair identification path in sensors.c. The existing sensor test
scenarios only script the SmartSens 0x3107/0x3108 pair, and the scenario list contains no
dedicated SC1135 case for the new registers, leaving the added behavior without regression coverage.

CLAUDE.md: Test Hardware-Independent Logic Without Disabled Assertions: CLAUDE.md: Test Hardware-Independent Logic Without Disabled Assertions: CLAUDE.md: Test Hardware-Independent Logic Without Disabled Assertions: CLAUDE.md: Test Hardware-Independent Logic Without Disabled Assertions
src/sensors.c[475-477]
src/sensors_test.c[117-144]
src/sensors_test.c[228-236]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The new SC1135 detection path is not covered by the hardware-independent sensor probe regression tests, so its positive and negative identification behavior can regress unnoticed.
## Fix Focus Areas
- src/sensors_test.c[117-144]
- src/sensors_test.c[228-236]
- src/sensors_golden.txt[1-100]
## Recommended Fix
Add a SmartSens scenario that scripts `0x3008 = 0x60` and `0x3005 = 0x22`, verifies that it returns `SC1135`, and verifies a nearby negative value such as `0x3005 = 0x23` is rejected. Regenerate or update the committed sensor fingerprint output so the new expected identification is checked in CI.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

2. Failed sensor probes can alter cameras 🐞 Bug ☼ Reliability

Description

is_smartsens_sc1135() performs two additional 16-bit-register reads after the SmartSens probe has
already failed, and the generic I²C HAL sends each register address with a separate two-byte write.
On shared addresses such as Anyka’s 0x60, an 8-bit-addressed SOI sensor can interpret those bytes
as register writes, so an unrecognized device can be modified during detection.

Code

src/sensors.c[R476-477]

+    return i2c_read_register(fd, i2c_addr, 0x3008, 2, 1) == 0x60 &&
+           i2c_read_register(fd, i2c_addr, 0x3005, 2, 1) == 0x22;

Evidence

The new helper issues two 16-bit register reads, and the generic I²C implementation writes both
address bytes before reading. The fallback is reached after any unknown SmartSens ID, including zero
or 0xffff; on Anyka, SOI and SmartSens both probe address 0x60, while SOI uses one-byte register
accesses, so an SOI device that was not identified can receive the added two-byte transactions.

src/sensors.c[475-477]
src/sensors.c[714-724]
src/hal/common.c[108-129]
src/hal/anyka.c[8-20]
src/sensors.c[1180-1197]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The SC1135 fallback adds two 16-bit register reads on a bus address that may belong to an 8-bit-register sensor. The generic I²C HAL transmits the register address as a two-byte write before reading, so a failed SOI identification can receive unintended writes during SmartSens detection.
## Fix Focus Areas
- src/sensors.c[475-477]
- src/sensors.c[714-724]
- src/hal/common.c[108-133]
## Recommended Fix
Make the SC1135 fingerprint probe safe for shared addresses before issuing it. Prefer a transaction/API that performs a non-mutating combined register read for the target sensor, or gate the fallback to platforms and sensor-bus configurations where the address is known to use 16-bit registers; otherwise skip the fallback rather than sending potentially destructive two-byte register-address writes.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

Tip of the day

💡 Did you know, you can route each severity your way: inline, summary, both, or drop

More tips ↗ | Customize Qodo ↗ | Qodo docs ↗