Add 11 SmartSens chip ID detection cases

[josephnef]

Summary

Adds 11 missing SmartSens chip-ID → model-name mappings to detect_smartsens_sensor() in src/sensors.c. Previously these chip IDs returned via SENSOR_ERR() and showed up in the field as unknown sensors.

Source

All 11 mappings are transcribed from a public third-party compilation:

"思特威sensor的chipid整理-懒人必备" by 雨之小, CSDN, 2025
https://blog.csdn.net/fzktongyong/article/details/149630895
Licensed CC-BY-SA 4.0

The author claims 33 SmartSens chip IDs total. After cross-referencing against the existing detect_smartsens_sensor() switch, 22 of those 33 are already covered (with ipctool's coverage being substantially broader than the blog's — ~50 chip IDs total vs 33). The 11 below are the gaps.

Cases added

Chip ID	Model	Placed near	Notes
0x0031	SC031GS	top of switch (0x00xx group)	Global shutter
0x0108	SC035GS	top of switch	Global shutter
0x0132	SC132GS	top of switch	Global shutter
0x17cb	SC210IoT	after SC2235 family	Unusual high-byte 0x17
0xcb34	SC230AI	after 0xcb14	SmartClarity-AI 2MP
0xcb6a	SC231HAI	after 0xcb5c → SC2331	SmartClarity HAI
0x9c41	SC3336P	after 0xcc41 → SC3336	Mirrors 0x9c42 → SC4336P pattern (P-variant high byte 0xCx → 0x9x)
0x8e39	SC530AI	after 0xce1f → SC501AI	SmartClarity-2 5MP
0xce50	SC5336	after 0xce1f → SC501AI	DSI-2 5MP
0xc170	SC831AI	after 0xc143 → SC830AI	SmartClarity-3 HAI 8MP
0xeb2c	SC2355	end of switch	Mobile-segment 2MP

Decisions deliberately NOT made

The blog also reveals three chip IDs shared between two model names:

Chip ID	ipctool reports	Also marketed as
0xcd2e	SC401AI	SC430CS
0xce1f	SC501AI	SC500AI
0xcc41	SC3336	SC3338

I chose not to touch these. Commit b328d02 ("Fix SC3338 -> SC3336") established the project precedent of picking one canonical name per chip ID rather than surfacing aliases — these would all require maintainer judgment about which name to pick.

Apparent blog↔ipctool conflicts (not changed)

A few entries in the blog disagree with ipctool's existing switch:

• 0x2238 — blog says SC2232, ipctool currently says SC2315E (with comment "aka SC4239Р and SC307E"). ipctool wins; the existing comment shows this was field-validated.
• 0x2311 — blog says SC2310, ipctool says SC2315.
• SC850SL — blog says 0x9d1e, ipctool says 0xbd1e. Likely a typo in the blog (B↔9 hex confusion); ipctool's value is field-validated.

No changes made for these.

Caveat

These chip-ID values are not field-tested by me — they are transcribed from a third-party compilation. If anyone has these sensors on actual hardware and can run `ipctool` against them to confirm or refute, that would be valuable. Reverting any individual case is trivially safe.

Test plan

• Build cleanly on standard ipctool CI targets (no logic changes outside the additive case blocks; no new symbols, includes, or APIs)
• When confirmation hardware is available: verify each new mapping against an actual sensor via ipctool output

🤖 Generated with Claude Code