Linux Driver Will Expose Voltage Inputs for Raspberry Pi SBCs

In brief — 2026-06-05 · A new Linux kernel driver exposes Raspberry Pi SBC voltage inputs to the standard hwmon monitoring interface, letting builders read board rails directly from lm-sensors and homelab dashboards instead of squinting at undervoltage lightning-bolts.

The new Raspberry Pi voltage-input Linux driver registers the SBC's onboard voltage rails as a standard hardware-monitoring (hwmon) device, so userspace tools — lm-sensors, Prometheus exporters, Home Assistant integrations, Grafana panels — can read live rail readings the same way they read CPU temperatures. For Raspberry Pi 4 owners who currently rely on the kernel's coarse undervoltage flag and vcgencmd get_throttled, this is the difference between "something tripped" and "the 5V rail sagged to 4.72V at 14:03 under sustained load."

What happened (the driver, which SBCs, what it surfaces)

The change landed as a fresh hwmon driver targeting Raspberry Pi SBCs, reported in the makers row by Phoronix in early June 2026 under the headline "Linux Driver To Expose Voltage Inputs For Raspberry Pi SBCs." Per the Phoronix report, the driver hooks the Pi's onboard voltage measurement points into the kernel's hwmon subsystem, which is the same framework that already exposes CPU package voltages on x86 desktops, server PSU rails on IPMI-equipped boards, and ATX 12V/5V/3.3V readings on motherboards with Super I/O chips.

Functionally, that registration matters because everything downstream of hwmon — sensors from lm-sensors, libsensors, the /sys/class/hwmon/hwmon/in_input sysfs nodes, Prometheus node_exporter's hwmon collector, Netdata, Glances, Cockpit — picks up new voltage channels automatically with zero per-tool configuration. The kernel hwmon documentation describes the sysfs interface every monitoring stack already speaks: in0_input for a voltage reading in millivolts, in0_label for a human-readable name, optional in0_min / in0_max thresholds, and in0_alarm for cross-the-line warnings. Once the Pi driver populates those nodes, the entire Linux observability ecosystem inherits SBC voltage telemetry for free.

The change is most directly relevant to current-generation Pi boards including the Raspberry Pi 4 Model B 8GB, which is the volume target for homelab, kiosk, retro-emulation, and edge-compute deployments. Per the Raspberry Pi 4 product page, the board specifies a 5V/3A USB-C power input and exposes onboard power-management circuitry that has long published throttling status via the VideoCore firmware — the new driver makes those same measurement points first-class Linux citizens.

Coverage by board model depends on the kernel version and the specific commit; as with most kernel work, the driver lands in mainline first, gets backported to long-term stable kernels next, and then arrives in distro kernels (Raspberry Pi OS, Ubuntu for Pi, Armbian, DietPi) on whatever cadence each distribution maintains. Operators on older 5.x or early 6.x kernels will need to wait for a backport or roll a current kernel themselves.

Why it matters (under-voltage detection, homelab monitoring, why builders care)

Undervoltage is the single most common quiet failure mode on a Raspberry Pi. The board itself rarely dies; instead, a marginal power chain — an underrated USB-C charger, a thin or long cable, a hub with too many devices, a PoE HAT under load — drops the 5V rail below the firmware's threshold and the board responds by throttling the CPU, disabling USB ports, or rebooting. On a desktop with a 750W ATX PSU and 12V rails that simply do not move, none of this happens. On an SBC, it happens constantly and silently.

Today, the canonical detection path is the firmware's binary undervoltage flag, surfaced through vcgencmd get_throttled as a bitfield (0x50005 meaning "currently throttled and has been throttled since boot"). That is useful but coarse: it tells you something tripped, not how close to the edge the rail sits during your normal workload, not whether a specific peripheral plug-in caused a sag, not what the actual voltage was at the moment of the alarm. Per the Phoronix coverage of the new driver, exposing the inputs as hwmon channels gives operators access to the continuous voltage signal, not just the latched alarm.

For homelab operators that closes several real gaps:

• Continuous trending. Graph the 5V rail over a week and you can see whether the supply is degrading, whether a specific cron job (heavy I/O, a pi-hole gravity rebuild, a restic backup spinning up an external USB SSD) drives a measurable dip, whether ambient temperature correlates with sag.
• Alerting before the lightning bolt. With in0_min thresholds you can fire a Prometheus alert at 4.85V rather than wait for the firmware's hard cutoff at 4.63V.
• Fleet comparison. A rack of identical Pis running identical workloads can be compared rail-by-rail; the outlier almost always has a bad cable or a marginal supply.
• Postmortems with data. When a Pi reboots at 3am you currently get a kernel log gap and a throttle flag. With voltage history you get "the 5V rail dropped to 4.41V over a 12-second window starting 03:14:08," which points the investigation at the power chain rather than the SD card or the kernel.

This is particularly valuable for builders running Pi 4 8GB units as 24/7 services — Home Assistant gateways, Pi-hole + Unbound resolvers, Frigate NVR boxes with a Coral USB accelerator, Octoprint print servers, light Kubernetes nodes in a k3s cluster, retro-emulation arcade cabinets. Any of those workloads can mask a power problem for weeks before manifesting as data corruption or random crashes.

Builders deploying the Pi 4 8GB as part of a kit — e.g., the CanaKit Raspberry Pi 4 8GB Starter Kit or the LABISTS Raspberry Pi 4 8GB Complete Kit — should pay extra attention to which USB-C supply ships in the box. A bundled supply rated at 5V/3A is the spec target, but real-world output under transient load is what the new driver will let you actually verify. Once the driver is available in your kernel, a 10-minute test under stress-ng --cpu 4 --vm 2 while logging sensors output tells you whether the bundled supply holds the rail or sags.

Common pitfalls

Even with the new driver in place, a few failure modes are worth flagging:

• Thin or long USB-C cables. A 2m no-name cable can drop several hundred millivolts at 3A. The driver will show you the sag at the board, but the cable is the fix.
• Powered USB hubs that backfeed. Some hubs push current back up the upstream port and confuse the Pi's PMIC. The voltage channel may look fine while the board misbehaves.
• PoE HATs under transient load. A PoE HAT rated to 802.3af supplies enough average power for a Pi 4 but can sag during burst loads (camera capture + USB SSD write). The new driver makes that sag visible.
• Charger negotiation failures. Some USB-C PD supplies negotiate down to 5V/1.5A if the e-marker chip is absent or misreports. The board boots, then browns out on first heavy load.
• SD-card induced reboots misattributed to power. Not every reboot is undervoltage; corrupted SD cards reboot too. The new driver helps you separate the two by giving you a voltage timestamp at the moment of the crash.

Reading the new sysfs nodes

Once the driver is loaded, the standard hwmon access patterns apply. The kernel hwmon documentation specifies the conventions:

sensors from lm-sensors will auto-discover the device once the driver is loaded; node_exporter --collector.hwmon will publish each channel as a Prometheus metric node_hwmon_in_volts{chip="...",sensor="in0"} ready to scrape from any homelab Grafana dashboard.

When NOT to bother

This driver is interesting if you operate Pis as 24/7 services, run them in mixed-power environments (PoE, battery, solar), or have a history of unexplained reboots. If you run a single Pi 4 8GB on a known-good first-party USB-C supply for hobby projects that you power-cycle anyway, the upgrade is nice-to-have, not urgent. The existing vcgencmd get_throttled check covers the binary "did it trip" question, and the firmware's lightning-bolt overlay on the HDMI output remains a reasonable bedside lamp. The new driver is for builders who want to see the curve, not just the alarm.

How this compares to existing tooling

Pi owners have had several partial answers to the undervoltage question for years, and the new hwmon driver complements rather than replaces them. The firmware's vcgencmd family — vcgencmd get_throttled, vcgencmd measure_volts core, vcgencmd measure_temp — has long been the canonical user-space probe, and as the kernel hwmon documentation notes, hwmon is intentionally a thin abstraction over hardware sensors that lets existing tools coexist with new ones. The practical comparison:

For most operators the right play is to keep vcgencmd checks in existing health scripts (they remain stable across kernel versions), wire the new hwmon channels into long-term monitoring once available, and treat the firmware lightning bolt as the final-fallback signal when no remote monitoring is reachable. Per the Phoronix coverage of the patch, the driver is an addition to the existing stack, not a replacement for it.

Practical homelab integration plan

For a small Pi fleet — say four or five Raspberry Pi 4 Model B 8GB boards running mixed homelab services — the integration path once the driver lands looks roughly like this. First, confirm your kernel exposes the device by checking /sys/class/hwmon/ for a new entry after a reboot on the updated kernel; the kernel hwmon documentation covers the sysfs layout. Second, install lm-sensors (apt install lm-sensors) and run sensors to confirm the new channels appear with sensible labels. Third, install prometheus-node-exporter with the hwmon collector enabled; the exporter will pick up the new channels automatically and publish them as node_hwmon_in_volts. Fourth, in your Prometheus rules file, add an alert that fires when any Pi's 5V rail trails its 24-hour rolling median by more than 100mV, which catches drift before it crosses the firmware's hard threshold. Fifth, build a Grafana panel that overlays the rail trace against a histogram of node_load1 so you can visually correlate sag with workload bursts.

For a kit-based deployment using the CanaKit Raspberry Pi 4 8GB Starter Kit or the LABISTS Raspberry Pi 4 8GB Complete Kit, the same plan applies, but with one extra step: run a 30-minute stress-ng soak on day one and screenshot the voltage trace. That gives you a baseline you can compare against in three months when the bundled supply or cable starts to degrade — a particularly common failure mode on budget USB-C cables that see daily heat cycling next to a CPU running near its thermal envelope.

What this does not solve

The new driver is a measurement upgrade, not a power-delivery upgrade. The same physical-world constraints that have always governed Pi power apply unchanged: USB-C cables have measurable resistance, supplies have output regulation tolerances, peripherals draw transient current that single-rail supplies cannot always service, and the Pi 4's USB-C input is famously sensitive to e-marker negotiation on some power-delivery supplies. The driver lets you observe these problems with higher fidelity; it does not make them go away. As the Raspberry Pi 4 product page notes, the official recommendation remains the first-party 5.1V/3A USB-C supply for any deployment where reliability matters, and that recommendation is unchanged by the new hwmon support.

Per the Phoronix report, the patch also does not retrofit the new sensor channels onto older Pi generations that lack the underlying measurement hardware on-die; older Pi 3 and Pi Zero boards will continue to depend on firmware-side throttle reporting for the foreseeable future. Operators running mixed-generation fleets should plan for two monitoring code paths until the older boards age out of service.

The source

The original report is Phoronix's coverage of the Linux driver patch that exposes Raspberry Pi voltage inputs through hwmon. Phoronix's tracking of kernel patches and ARM platform support is the canonical public source for this kind of upstream Linux change before it hits distro kernels, and the hwmon framework itself is documented in the upstream kernel hwmon documentation. For board-level reference — pinout, official PSU requirements, supported peripherals — the Raspberry Pi 4 Model B product page remains the authoritative document, particularly the USB-C power input spec that the new driver will let you finally instrument under load.

For owners chasing the lightning-bolt warning on a Raspberry Pi 4 Model B 8GB board today, the recommended sequence is unchanged: verify the supply, verify the cable, verify the peripherals. Once the new driver reaches your kernel, that same diagnostic flow gets a continuous voltage signal underneath it instead of a binary trip flag.

Key Takeaways

• A new Linux kernel driver registers Raspberry Pi SBC voltage rails as a standard hwmon device, per the Phoronix report.
• Once loaded, the rails become available to lm-sensors, Prometheus node_exporter, Netdata, Home Assistant — every monitoring stack that already reads hwmon.
• Operators of the Raspberry Pi 4 Model B 8GB gain a continuous voltage signal instead of relying solely on the binary vcgencmd get_throttled flag.
• This is most useful for 24/7 homelab and edge workloads where marginal power chains silently cause throttling, SD-card corruption, or random reboots.
• Availability depends on kernel version; expect the change to reach Raspberry Pi OS and downstream distros after the usual mainline-then-backport cycle.
• The kernel hwmon documentation describes the sysfs interface every monitoring tool already speaks.

Citations and sources

• Phoronix — Linux Driver To Expose Voltage Inputs For Raspberry Pi SBCs
• Raspberry Pi 4 Model B — official product page
• Linux kernel hwmon subsystem documentation

This piece is editorial synthesis based on publicly available information. No independent first-party benchmarking is reported.