Justin Hammond 69386aa6c0 drivers/power: Describe the regulators through procfs. ... The regulator framework has no way out to userspace: consumers reach a rail by name from inside the kernel, which is the right interface for controlling one, but it leaves a board with regulators offering no way to see what they are doing, and a newly written regulator driver cannot be looked at without writing a consumer for it first. Adds /proc/regulator, behind REGULATOR_PROCFS, listing every registered regulator: its present voltage, the range it will accept, whether it is enabled, how many consumers hold and enable it, its supply, and whether it is always on or expected on at boot. Lines carry the same key:value tokens in the same order, so the file is machine parseable. The last two are worth reading beside the consumer count, since a rail enabled with no consumers is expected rather than suspect when either is set. A part usually measures more than the framework has fields for, so struct regulator_ops_s gains an optional describe method: it writes key:value text and the renderer appends it to that rail's line. This is how a driver reports what only it knows, an input voltage, an output current, a temperature or a fault word, without the framework growing a field per part or the driver growing procfs code of its own. It is called with the list mutex held and never from interrupt context, so reading the part over a bus is allowed. The voltage and the enabled state are read back from the hardware rather than recalled, so a rail the boot loader set and nothing has touched since reads as it actually is. Both calls can fail, and a failure reports - rather than an errno formatted as a voltage or a rail that looks switched on. Reading the hardware is also why this takes the list mutex directly rather than calling regulator_list_lock(), which additionally disables interrupts so that callers in interrupt or idle context are safe. Asking a regulator on a bus what it is doing means a transfer, and a transfer waits; a task reading a file can afford to wait and an interrupt handler cannot. procfs_register() appends without checking for duplicates, so the entry is claimed once for the lifetime of the system rather than whenever the list is empty. It also needs FS_PROCFS_REGISTER, which the option now depends on rather than only FS_PROCFS. Documents the framework, which had no page at all: the consumer interface and what counted enables mean, what a driver supplies, and the new entry. The entry is read only. What voltage a rail may be is knowledge its consumers hold, and arranging the order between them is what the framework is for, so moving one from a shell would step around the part that matters. Assisted-by: Claude:claude-opus-5 Signed-off-by: Justin Hammond <justin@dynam.ac>		2026-08-18 17:28:02 +08:00
..
block	drivers/eeprom: Retrieve the geometry	2025-11-13 08:57:52 -03:00
character	drivers/analog: add digital potentiometer driver support	2026-08-08 18:37:08 +08:00
special	drivers/power: Describe the regulators through procfs.	2026-08-18 17:28:02 +08:00
thermal	Documentation: fix spelling	2025-05-15 11:33:41 +08:00
index.rst	Documentation/virtio: add VirtIO framework documentation	2026-01-28 13:09:19 -03:00