hal: re-enable the sensor clock before every probe, not once per process

[widgetii]

getsensorid() reads the sensor over i2c, so the sensor has to be clocked to answer. On Ingenic that clock is turned on by setup_hal_ingenic(), which runs from hw_detect_system() inside getchipname() — and getchipname() caches:

const char *getchipname() {
    if (*sysid) return sysid;              // early-out on every later call
    setup_hal_fallback();
    if (!hw_detect_system()) return NULL;  // the only path that reaches the HAL setup

So the HAL setup happens exactly once per process. That holds while nothing takes the clock away again — and something does. A vendor SDK gates it off when it tears its pipeline down:

	/proc/jz/clock/cgu_cim/enable
pipeline up	enabled
after teardown	disabled

Every probe after that reads an unclocked sensor and reports that the board has none.

Why this is easy to misdiagnose

A fresh process always gets the right answer, because its first getchipname() runs the HAL setup again and turns the clock back on. So ipcinfo -l from a shell answers sc2332_i2c at the very moment a long-lived caller is being told there is no sensor.

That reads as a bug in the caller, or as flaky hardware. It also makes it look intermittent: any probe that happens to follow an ipcinfo run succeeds, as does one attempted while the SDK is already down — there was no teardown to gate the clock off.

Change

Make it a HAL hook and call it before each probe, rather than relying on a setup that runs once. NULL for every SoC that needs nothing done — all of them but Ingenic today — and cleared in setup_hal_fallback() so detection cannot inherit a previous target's hook.

27 lines, no behaviour change on any SoC that doesn't set it.

Verified on hardware

t31 (sc2332), with a caller that probes once per pipeline reload:

	result
before	first probe finds sc2332_i2c, every later one finds nothing
after	sc2332_i2c on all of them, across repeated SDK teardowns

Measured by running that caller with its own detection cache disabled, so every reload performed a real i2c probe:

reload 1 -> Autodetected sensor as 'sc2332_i2c'
reload 2 -> Autodetected sensor as 'sc2332_i2c'
reload 3 -> Autodetected sensor as 'sc2332_i2c'
autodetect failures: 0

Context

Found from majestic, where this surfaced as sensor autodetection failed and then Cannot start SDK on every SIGHUP reload — the camera lost video until someone restarted it by hand. Majestic is fixing its side by caching the first detection, since the sensor cannot change while the process runs; this is the underlying reason a re-probe could not work, and fixing it here means any consumer that probes more than once gets a correct answer.

Only Ingenic is verified on hardware — it is also the only SoC whose behaviour changes.

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

PR Summary by Qodo

Re-enable Ingenic sensor clock before every probe

🐞 Bug fix 🕐 10-20 Minutes

AI Description

• Adds a platform hook to prepare sensors before each hardware probe.
• Re-enables Ingenic sensor clocks after vendor pipeline teardown.
• Preserves existing behavior on platforms without clock preparation requirements.

Diagram

sequenceDiagram
    participant Caller
    participant Probe as Sensor Probe
    participant HAL as HAL Dispatch
    participant Ingenic as Ingenic HAL
    participant Clock as Sensor Clock
    participant Sensor as I2C Sensor
    Caller->>Probe: Request detection
    Probe->>HAL: Resolve platform
    HAL-->>Probe: Return clock hook
    opt Ingenic hook configured
        Probe->>Ingenic: Enable clock
        Ingenic->>Clock: Ungate clock
    end
    Probe->>Sensor: Read sensor ID
    Sensor-->>Probe: Return identity

Loading

High-Level Assessment

The following are alternative approaches to this PR:

1. Repeat full HAL setup

• ➕ Reuses existing Ingenic setup without introducing another callback.
• ➕ Automatically reapplies every platform initialization step.
• ➖ Repeats unrelated initialization and potential side effects before every probe.
• ➖ Couples probe correctness to broad setup behavior rather than the required clock action.

2. Call Ingenic logic directly

• ➕ Minimizes dispatch machinery for the only currently affected platform.
• ➖ Breaks the platform-neutral sensor probing boundary.
• ➖ Makes future SoC-specific probe preparation harder to add cleanly.

Recommendation: Keep the optional HAL hook. It isolates the repeatable pre-probe requirement, preserves no-op behavior on other SoCs, and avoids rerunning broad platform setup or coupling generic sensor detection to Ingenic internals.

Files changed (4) +27 / -0

Bug fix (4) +27 / -0

common.cAdd and reset the sensor-clock HAL hook +4/-0

Add and reset the sensor-clock HAL hook

• Defines the process-wide sensor preparation callback. Fallback HAL setup clears it so platform detection cannot retain a hook from a previously selected target.

src/hal/common.c

common.hExpose the per-probe sensor-clock callback +6/-0

Expose the per-probe sensor-clock callback

• Declares the optional HAL hook and documents that platforms may need to restore sensor readiness before every probe.

src/hal/common.h

ingenic.cRegister Ingenic clock restoration for repeated probes +6/-0

Register Ingenic clock restoration for repeated probes

• Assigns the existing Ingenic clock-enablement routine to the new HAL hook while retaining its initial setup invocation. This allows later probes to recover after vendor pipeline teardown disables the clock.

src/hal/ingenic.c

sensors.cPrepare the sensor clock before each identity probe +11/-0

Prepare the sensor clock before each identity probe

• Invokes the optional HAL preparation hook after platform detection and before opening the sensor bus. Repeated Ingenic probes can therefore read the sensor after its clock has been gated off.

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

Tip of the day

💡 Did you know, you can reply 'qodo' on any finding to push back, ask questions, or dig deeper

More tips ↗ | Customize Qodo ↗ | Qodo docs ↗