ina4230: "Unable to reset device" during probe on I2C bus 2 (addr 0x46)

[Yury-MonZon]

The ina4230 hwmon/power-monitor driver fails to reset the device at probe time.

[    1.013778] /soc/i2c@2ac50000/typec-portc@22: Fixed dependency cycle(s) with /soc/i2c@2ac50000/charger@6b
[    1.015759] ina2xx 2-0045: power monitor ina219 (Rshunt = 4000 uOhm)
[    1.025283] ina4230 2-0046: Unable to reset device

Build: flipperone-a9438e-build-1182-test-vop2-dclk-check

[munzzyy]

Dug into this one. The driver checks out against the TI datasheet (SBOSAD4): CONFIG2 is 0x21, RST is bit 15 and self-clears, which matches ina4230.c exactly, and ina4230_resume() doesn't do any readback-verify that could race the self-clear. So I don't think this is a register-map or driver-logic bug.

The lead I did find is board-level. Per Table 6-1, address 0x46 is only reachable with A1=VS and A0=SDA, meaning the address pin is strapped to a live bus line. The working ina219 next door at 0x45 is A1=VS/A0=VS, all static rails. The datasheet says the address pins are sampled on every transaction and warns to "establish the pin state before any activity on the interface occurs". The failing reset write is the first transaction ever sent to 0x46 (pm_runtime_get_sync() during probe), so if SDA wasn't sitting clean at idle-high when the chip's address comparator sampled it, the part would simply never ACK as 0x46, and regmap would surface exactly this error.

That makes it a strapping/bus-timing question rather than a driver bug. Worth scoping SDA/SCL on i2c2 around the first transaction burst at boot, and double-checking the A0 strap on the schematic. I don't have hardware, so this is datasheet-derived inference: the strongest lead I found, not a confirmed root cause.

[munzzyy]

Separate from the probe failure in #12, three things I hit reading ina4230.c against SBOSAD4. From source only. No board here.

1. Probe builds reg_config1 and clears CHx_EN for DT-disconnected channels. It never writes it. The part sits at its F127h reset value while the shadow says F327h, so samples reports 4 while the chip averages 1.

2. ina4230_resume() writes RST through the regcache. CONFIG2 is not volatile and RST self-clears, so bit 15 sticks. regcache_sync() then writes CONFIG2 last and re-resets the chip after restoring CAL1-4. The intended reset becomes a no-op.

3. ina4230_read_power() casts POWER to int16_t. Section 7.1.9 calls it unsigned. Raw counts from 32768 up read back negative.

Happy to send patches, but it is your driver. Want them, or will you take these yourself?

[alchark]

Hi @munzzyy, thanks for looking into this! I have to admit that bringing this driver up to shape for upstream has been dangling somewhere in the lower middle of my priority list for some time now. It does need some more love in the probe routine and runtime PM paths, but more importantly it needs more extensive testing in various edge cases which I just haven’t had the time to do. Those INAs won’t stay in mass produced revisions of the Flipper, so they keep getting jumped by other priorities

[munzzyy]

Thanks, that context helps. Two of the three sit exactly where you said the work is: CONFIG1 never reaching the chip at probe, and RST sticking in the regcache so the sync re-resets the part on resume. The POWER cast is a one-liner.

No rush from me. They stay in a branch and I will send them whenever this climbs your list, or not at all if the part is leaving the design anyway. Just say the word.