When you write to a PMBus voltage regulator through sysfs, the kernel's pmbus core driver may silently send the wrong voltage to your hardware. The read path works correctly; the write path doesn't. And here's the critical part: the driver returns success either way.
The vulnerability is in pmbus_data2reg_vid(), which converts a user-requested voltage into the PMBus VID code for the write path. Unlike its inverse function pmbus_reg2data_vid(), it ignores the vrm_version flag. Write 200mV in non-VR11 mode and the hardware receives 1080mV. No error. The chip does exactly what it's told. From the caller's perspective, everything looks fine until silicon behaves unexpectedly.
This isn't an edge case. It's what happens for any voltage write when vrm_version is not VR11. The encoding drift is deterministic and silent. The asymmetry probably happened because a developer fixed the read path for a non-VR11 integration, tested reads (which worked), and never traced the inverse path to update writes. That's not negligence — it's how modular code review works. You review functions, not inverse-function pairs as a unit.
The ergonomic failure is worse than the bug itself. Reads work. Sysfs returns success. When hardware acts up, you debug the hardware — not the kernel's pmbus core. The cognitive load is exactly backwards from where it should be.
The fix is trivial: mirror the switch statement to add vrm_version handling to pmbus_data2reg_vid(). But this driver now has a test that others like it probably don't. The real question is what other pmbus_data2reg_* and pmbus_reg2data_* pairs in this file have the same derivation-and-divergence pattern. The VID case is tested. What's the discovery story for the rest? And which subsystems are silently relying on VR11 as a default without ever testing writes in a non-VR11 context?