I build tools to solve my own oddly specific problems, then release them as free and open source so everyone else can enjoy the chaos too.
I’m the kind of person who looks at a missing feature and thinks, “That probably won’t take long.” This is almost never true.
A perfect example is my KONKR Pocket FIT Elite. I wanted better charging controls while running ROCKNIX. Nothing dramatic—just bypass charging and a sensible fast-charge mode.
A normal person might have waited for somebody else to implement it.
I accidentally began a small electrical engineering novel.
The first mystery looked simple: Android could stop charging the battery while keeping the handheld powered from USB, so I only needed to discover which control it used. Easy.
The first candidate was firmware property 47. The module loaded, the device survived, and absolutely nothing happened. After more digging, I discovered the property table had been read backwards. The real answer was property 29.
Classic.
Property 29 worked, but the firmware replied using an opcode the Linux driver did not understand. After teaching the driver how to validate that response, bypass finally worked: USB remained connected while battery current dropped almost to zero.
The battery status still claimed it was charging, because apparently even the kernel was in denial. So I fixed that too.
Then I made the terrible mistake of wondering whether the device’s proper fast-charging hardware could work under ROCKNIX.
Stock Android knew about two HL7139 charge pumps. ROCKNIX knew about neither of them. Android also had a Qualcomm firmware bridge, a ThunderComm charging coordinator, two I²C devices, custom protection settings, and an entire state machine quietly managing the electrical equivalent of “please do not turn this handheld into a toaster.”
So I captured Android’s live device tree, decompiled it, traced the hardware and found:
- one charge pump at
0x5f; - another at
0x5e; - interrupt GPIOs 68 and 66;
- a disabled I²C bus hiding in plain sight; and
- a stock coordinator deciding when Qualcomm should step aside and let both pumps take over.
The existing Linux HL7139 driver assumed there would only ever be one pump. My device had two, because apparently one source of danger wasn’t enough.
I built a dual-instance driver with separate master and slave controls, ADC telemetry, fault handling and one very important default: both pumps stay OFF until something responsible explicitly enables them.
The first live probe immediately found a duplicate wake-IRQ problem. The kernel politely returned EEXIST, I rolled everything back, fixed the driver and tried again. Both physical chips then appeared, identified themselves as revision 2, survived suspend and resume, and continued doing absolutely nothing—which, at that stage, was exactly the success condition.
Next came Qualcomm PPS voltage control. I moved the input from 9 V down to 5 V and back while both pumps remained off. That revealed another fun detail: the voltage you request from the charger is not necessarily the voltage that reaches the board under load.
Then came the Qualcomm hand-off. Android asks its normal charging path to drop to 13 mA before enabling the external pumps. My first module exposed the right control but forgot to advertise one of its supported enum values, so Linux responded with EINVAL.
Rollback. Fix. Rebuild. Continue.
Eventually the device could safely move from normal Qualcomm charging to the external pumps and back again. Every test had independent limits, explicit arming phrases, build-ID checks, hash verification and a rollback trap waiting nearby like a nervous parent.
I started at 20 W.
Then 25 W.
Then 30 W.
At 30 W, the handheld charged happily through both pumps with roughly 3% current imbalance. Physical unplug worked perfectly: both pumps switched off and the coordinator failed closed.
Reconnecting the cable did not work perfectly.
The charger returned at roughly 5.5 V and 9 mA while the battery sat there discharging, presumably disappointed in me. The shutdown path had cleared its pending restore request a little too enthusiastically, so nothing woke normal Qualcomm charging after reconnection.
I fixed the lifecycle, repeated the physical unplug test, and watched untouched reconnect climb from 9 mA through 0.494 A, 1.25 A, 2.844 A and finally 4.10 A.
Thirty watts passed. Thirty-four watts passed.
Then came the final boss: 38 W.
The first 38 W run failed closed at a requested 9.220 V because one pump measured 8.468 V. The configured tolerance was 750 mV.
The difference was 752 mV.
Two millivolts. A deeply rude two millivolts.
I could have changed 750 to 753 and declared victory. Instead, I built a diagnostic kernel module so the driver could explain exactly which guard had fired. It reproduced the same boundary. Then I built a ramp-hold experiment to test whether the voltage simply needed time to catch up.
It didn’t. The system safely plateaued around 33 W.
At this point the correct response was obviously to boot stock Android, extract three kernel modules and their BTF data, disassemble the original charging coordinator, capture thousands of lossless I²C events, and analyse 284 dual-pump telemetry samples.
Perfectly normal weekend behaviour.
That investigation revealed the actual mistake: I was comparing a charger control setpoint with a physical voltage measurement. Android kept the requested voltage as bookkeeping and compared the pumps against the separately measured USB voltage.
In other words, the pumps were fine. My comparison was comparing apples with a strongly typed orange.
I corrected the model without relaxing any current, power or temperature limits. A new 38 W run completed safely, but the battery-current regulator correctly held it around 36 W. Rather than raising the safety ceiling to make the bigger number appear, I accepted what the evidence was saying.
Fast mode became 36 W.
The 36 W build passed a continuous guarded hold, clean rollback and Qualcomm recovery. Then I ran 720 more telemetry samples and recorded 139 columns of data covering 55 thermal zones, 56 hardware-monitor temperature channels, battery state, USB state and both charge pumps.
Because apparently “it seems fine” is not a measurement.
I followed that with matched five-minute Qualcomm and dual-pump runs starting at the same battery percentage and temperature. At nearly equal input energy, the dual-pump path delivered more average battery current and finished one degree cooler.
I still refused to call it laboratory efficiency data, because the readings came from asynchronous sysfs channels and system load was not independently measured.
That sentence probably explains me better than this entire story.
The preserved timeline covers roughly 51 hours from the first charging comparison to the final recovery archive, spread across a very intense three-day sprint. One particularly questionable day included validating 25 W, 30 W and 34 W; failing and diagnosing 38 W; reverse-engineering Android; correcting the voltage model; validating 36 W; and beginning the thermal comparison.
I cannot confirm how much sleep occurred. The timestamps have requested legal representation.
The final design has three deliberately boring modes:
- Normal: native Qualcomm charging;
- Slow: manually selected dual-pump charging at 25 W;
- Fast: manually selected dual-pump charging at 36 W.
Nothing automatically re-enables after unplugging, rebooting, suspending, bypassing, reaching a charge limit or encountering a fault. Anything suspicious sends the device back to the normal Qualcomm path with both pumps explicitly off.
That is basically how I work: curiosity gets me into trouble, evidence gets me back out, and somewhere along the way the “tiny personal fix” becomes a driver, a state machine, seventeen handover documents, several recovery artifacts and enough checksums to frighten a small database.
I build things for myself because I need them.
I share them because someone else probably needs them too.
And if something I made saves you time, effort, or one tiny piece of your sanity: