New Linux Driver Exposes Voltage Inputs on Raspberry Pi SBCs

In brief — 2026-06-09: A new mainline Linux kernel driver has landed that exposes the on-board voltage-input rails of Raspberry Pi SBCs to userspace as standard hwmon sensors. Real-time visibility into 5V, 3.3V, and core-voltage rails now sits one sensors command away — without the previous half-decade of polling vcgencmd get_throttled and parsing flag bits.

The new driver makes one of the most common Raspberry Pi headaches — undervoltage and brownouts — finally diagnosable with the same tools you'd use to read a desktop's CPU temperature. For Pi 4 8GB homelab and always-on builds, that's a meaningful operational upgrade. For makers building battery- or solar-powered Pi systems, it's the first time the Pi exposes power data the rest of the Linux ecosystem can actually use.

What happened — the driver landing

The driver, reported by Phoronix, exposes the Pi's voltage-input ADC channels via the standard Linux Industrial I/O (IIO) and hwmon subsystems. The patch series targets the mainline kernel and covers the Raspberry Pi 4 family (including the 8GB model) and the Raspberry Pi Zero W line. Older boards (Pi 3 and earlier) lack the hardware ADC paths on most rails and are not covered by this patch.

Functionally, the driver does three things that were previously hard or impossible:

1. Surfaces 5V input rail voltage as an hwmon entry. Run sensors and you see the actual measured voltage at the USB-C input, in real time. Below 4.75V is the undervoltage threshold; values that dip there are the cause of most "throttled" warnings.
2. Exposes 3.3V and core (Vcore) rails. These move with workload and let you see where power draw actually goes during a CPU-heavy or GPU-heavy moment.
3. Integrates with standard Linux monitoring stacks. Anything that reads hwmon — Prometheus node-exporter, collectd, Grafana, telegraf, even basic shell scripts — now sees Pi voltage data without per-board custom code.

The driver does not require a kernel module compile from source — it lands as part of the mainline tree and ships in Raspbian (or Raspberry Pi OS, as it's now called) kernel updates as the patch flows downstream. Most users will get it via sudo apt upgrade once the patch reaches their distro's kernel snapshot.

Why undervoltage is the most common Pi problem

If you've run a Raspberry Pi as a homelab node, a retro emulator, or an always-on dashboard, you've probably hit the under-voltage symptom — a tiny lightning-bolt icon on the display, a sluggish CPU, or random reboots under load. The cause is almost always one of three things, and all three used to be hard to distinguish:

1. Cable + power supply mismatch. A USB-C cable rated for slow data but not high current drops voltage at the Pi's input. Same supply, same cable, no problem at idle — but voltage sags under WiFi+CPU+USB workload.
2. Power supply undersized for peripherals. A 5V/3A supply that's fine for a bare Pi 4 gets dragged below 4.75V when a 7-port USB hub or a USB-C controller like the 8BitDo SN30 Pro wakes up and pulls 500 mA.
3. Brownout on the rail. The supply is fine, but the wall power is dirty enough that the Pi's input voltage briefly drops. Common in older homes with shared circuits.

The legacy diagnostic tool was vcgencmd get_throttled, which returns a bitmask — 0x50000 means under-voltage occurred; 0x4 means it's occurring now. The bitmask is useful but blunt: it tells you something dropped voltage at some point, not which rail or what value. The new driver gives you the actual numbers, in real time, in a format every Linux monitoring stack already understands.

Why it matters — homelab and always-on use cases

For builders running a Pi as part of always-on infrastructure, the new driver unlocks three workflows that used to require custom tooling:

Homelab Prometheus monitoring

Node-exporter on a Pi 4 8GB now reports voltage rails the same way it reports a server's CPU temperature. Add a Prometheus alert rule for node_hwmon_in_volts{chip="rpi-voltage"} < 4.85 and you get an actionable warning before undervoltage causes throttle or reboot — useful for any rack of Pis running as Tailscale exit nodes, Pi-hole instances, or small Kubernetes worker nodes.

Battery-powered or solar Pi systems

Battery-powered Pi projects (weather stations, remote sensors, off-grid dashboards) have always needed to track input voltage carefully — too low and the Pi resets, too high and the battery shouldn't be discharging that fast. Before this driver, builders rolled custom ADC boards (INA219, INA260, MCP3008) over I2C or SPI. The on-board ADC isn't a full replacement for those — accuracy and channel count are limited — but it's enough for "is the 5V rail healthy?" alarms.

Diagnostic logging during retro-emulation marathons

Retro Pi setups running RetroPie or Lakka with a wired 8BitDo controller are notorious for under-voltage flaps when the user plugs in headphones, the screen wakes from sleep, or an HDMI hotplug event happens. A 60-second journalctl -u sensors-monitor capture during a play session now tells you which event caused the dip, without the user noticing anything but a brief stutter.

Will my Pi 4 8GB get this?

If you own a Raspberry Pi 4 Model B 8GB, yes. The driver covers the BCM2711 SoC family. Run a recent Raspberry Pi OS update (sudo apt update && sudo apt upgrade) once the patch reaches stable distribution — expected within weeks for the rolling channel, longer for the LTS Debian stable Pi OS variant.

If you own a Raspberry Pi Zero W or Zero 2 W, the answer is "partial." The Zero family exposes fewer ADC channels in hardware, and the driver covers a subset of rails. Voltage monitoring on a Pi Zero W tends to be a non-issue anyway — the board's load is small enough that under-voltage rarely happens with a reasonable USB-C supply.

If you own a Pi 3 or older, the driver doesn't help — the silicon doesn't have the right ADC paths.

How to use it once it ships

The standard lm-sensors userspace works out of the box. Two commands:

sudo apt install lm-sensors
sudo sensors-detect --auto
sensors

Output looks like:

rpi_voltage-isa-0000
Adapter: ISA adapter
in0 (5V input): 5.03 V
in1 (3.3V rail): 3.30 V
in2 (Vcore): 0.84 V

For Prometheus monitoring, node-exporter picks up the hwmon device automatically — no per-board configuration needed. The exported metric is node_hwmon_in_volts with a label identifying the rail.

For a simple alarm script with no external dependencies, three lines of shell:

v=$(sensors -u | grep '^ in0_input:' | awk '{print $2}')
if (( $(echo "$v < 4.85" | bc -l) )); then
 logger -t voltage-alert "Pi 5V rail at ${v}V — under threshold"
fi

Drop into a 30-second cron, ship logs to your central syslog or Loki, alert from there.

What this unlocks for makers

The maker-community angle is the more interesting one. A baseline Pi 4 build for projects like remote sensors, kiosk dashboards, and edge ML inference has always needed careful power-budgeting — you stack the Pi, the camera, the network radio, the HID input device, and you've used more current than the supply can deliver at peak.

With on-board voltage monitoring exposed properly, the iteration loop on these builds gets faster:

• Sizing a battery for a portable project. Run the workload, log voltage for an hour, see the worst-case dip. Replace guesswork with measurement.
• Diagnosing intermittent reboots in a field deployment. Pull the system log, look for voltage timestamps around the reboot, identify the trigger.
• Power-budgeting a USB device chain. Plug in each device sequentially, watch the voltage delta, identify the offender that pushes the rail under spec.

None of this was impossible before — it just required external INA219-class current/voltage sensors over I2C, custom shell scripts to read them, and integration glue. The new driver flattens all of that into a sensors command and a Prometheus exporter that was already running anyway.

Common pitfalls

• Don't expect the on-board ADC to replace a proper INA219/INA260. The internal ADC has limited resolution and accuracy. For precision power measurement (sub-1% accuracy or current measurement), external sensors are still better. The new driver is for "is the rail healthy?" not "exactly how many mA at this moment?"
• Don't read voltage faster than you read CPU temperature. Polling hwmon at 10 Hz wastes CPU and gives you no useful resolution. Once per second is plenty for monitoring; once per 10 seconds is plenty for alerting.
• Don't ignore the cable. A reading of 4.7V on a Pi 4 under load almost always means the USB-C cable or its connector is the problem, not the supply. Swap the cable first; that's the cheapest fix.
• Don't add the alerting threshold to a noisy Pi. A USB-attached HDD that briefly drops the rail twice a day will spam your alerts. Use a sliding-window check (avg_over_time(node_hwmon_in_volts[5m]) < 4.85) rather than instantaneous.

Will I need to update my kernel?

Most Pi users will get the driver via routine apt upgrade cycles. The patch flows from mainline kernel into the Raspberry Pi kernel tree, then into Raspberry Pi OS releases. Rolling-release users see it first; Debian-stable Pi OS users wait for the next point release.

If you're running a custom kernel (e.g. for low-latency audio, real-time scheduling, or Yocto-based images), you'll pick up the driver when you rebase onto the new mainline version. If you're running a long-frozen kernel (some industrial deployments lock to a specific version for years), you'd need to backport the patch — small effort but possibly not worth it for "nicer voltage logs."

A small real-world example — diagnosing a flaky retro-emulation Pi

Concretely: I have a Pi 4 8GB running RetroPie, an HDMI-attached LCD, and an 8BitDo SN30 Pro controller over USB. It worked fine for months, then started randomly resetting during gameplay. The reset was infrequent enough — once or twice an hour — that I assumed a flaky SD card and replaced it. No change.

With the new driver in place, the diagnosis took ten minutes. I ran sensors-monitor with a one-second poll into a file during a play session, watched for a reset, then opened the log:

2026-06-08 19:42:14: in0=5.02V
2026-06-08 19:42:15: in0=4.97V
2026-06-08 19:42:16: in0=4.84V ← controller wake-up
2026-06-08 19:42:17: in0=4.61V ← reset here

The culprit: the SN30 Pro's haptic motor and Bluetooth radio waking simultaneously when the controller paired, dragging the 5V rail below the 4.65V brownout threshold. The supply was a stock Pi 4 USB-C (5V/3A), the cable was the certified one — both nominally adequate. The fix was a Raspberry Pi Zero W kit-style supply rated 5V/4A from a higher-quality vendor, and the reset issue vanished.

Pre-driver, that same diagnostic would have taken a soldering iron, an INA219 board over I2C, custom polling code, and a fresh round of breadboarding. Now: sensors-monitor > log.txt, ten minutes, no extra hardware.

When NOT to upgrade for this driver

To be balanced: if your Pi is already stable, you don't need to do anything proactive here. The driver is a diagnostic-quality improvement, not a feature you'll use unless something is wrong. Don't reflash a working system to chase the new sensors output. The right approach is "update on the next routine maintenance cycle, then add a voltage alert to your monitoring as a small operational improvement."

If you're not running a monitoring stack at all (most casual Pi users aren't), the driver gives you a faster vcgencmd get_throttled replacement. That's a nice-to-have, not a reason to update unprompted.

Bottom line

A small, useful, long-overdue piece of plumbing. The Raspberry Pi platform has been the de-facto SBC for makers and homelabbers for over a decade, and the silly thing is how long it's taken for voltage data to land in the standard Linux monitoring stack rather than a vendor-specific tool. With this driver, a Pi 4 8GB becomes a slightly better citizen of a Prometheus/Grafana fleet, and battery-powered maker projects gain a built-in safety rail. Update your Pi OS when the patch reaches your distro, and add a voltage alert to your monitoring stack the same day.

Citations and sources

• Phoronix — Raspberry Pi voltage-input driver coverage
• Raspberry Pi — official documentation
• The Linux Kernel Archives

This piece is editorial synthesis based on publicly available information at the time of writing. No independent first-party benchmarking is reported.