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>
Permissions (Part 2)
Description:
In kernel builds, any unprivileged process running on the NuttX
device can open /dev/efuse and attempt to read/write fuse content.
Reading the fuses may provide valuable information to an attacker
controlling the user process. The write operation, in extreme cases
where the fuse blocks are not locked, may brick the device.
DISCLAIMER: I tried to be strict with the settings, better to relax them
later if it's needed.
This is part of https://github.com/apache/nuttx/issues/19410
See https://github.com/apache/nuttx/issues/19410
Compiles ok.
Signed-off-by: Catalin Visinescu <catalin_visinescu@yahoo.com>
debug.h is a NuttX-specific, non-POSIX header. Placing it in the
top-level include/ directory creates naming conflicts with external
projects that define their own debug.h.
This commit moves the canonical header to include/nuttx/debug.h,
following the NuttX convention for non-POSIX/non-standard headers,
and updates all in-tree references.
A backward-compatibility shim is left at include/debug.h that
emits a deprecation #warning and re-includes <nuttx/debug.h>,
allowing out-of-tree code to continue building while migrating.
Signed-off-by: Piyush Patle <piyushpatle228@gmail.com>
Nuttx currently has 2 types of sleep interfaces:
1. Signal-scheduled sleep: nxsig_sleep() / nxsig_usleep() / nxsig_nanosleep()
Weaknesses:
a. Signal-dependent: The signal-scheduled sleep method is bound to the signal framework, while some driver sleep operations do not depend on signals.
b. Timespec conversion: Signal-scheduled sleep involves timespec conversion, which has a significant impact on performance.
2. Busy sleep: up_mdelay() / up_udelay()
Weaknesses:
a. Does not actively trigger scheduling, occupy the CPU loading.
3. New interfaces: Scheduled sleep: nxsched_sleep() / nxsched_usleep() / nxsched_msleep() / nxsched_ticksleep()
Strengths:
a. Does not depend on the signal framework.
b. Tick-based, without additional computational overhead.
Currently, the Nuttx driver framework extensively uses nxsig_* interfaces. However, the driver does not need to rely on signals or timespec conversion.
Therefore, a new set of APIs is added to reduce dependencies on other modules.
(This PR also aims to make signals optional, further reducing the code size of Nuttx.)
Signed-off-by: chao an <anchao.archer@bytedance.com>
Most tools used for compliance and SBOM generation use SPDX identifiers
This change brings us a step closer to an easy SBOM generation.
Signed-off-by: Alin Jerpelea <alin.jerpelea@sony.com>
Use private naming to avoid conflicts with user applications
In file included from libuv/src/unix/internal.h:25,
from libuv/src/unix/udp.c:23:
libuv/src/uv-common.h:57: warning: "container_of" redefined
57 | #define container_of(ptr, type, member) \
|
In file included from nuttx/include/nuttx/list.h:47,
from nuttx/include/nuttx/tls.h:40,
from nuttx/include/nuttx/sched.h:48,
from nuttx/include/nuttx/arch.h:87,
from nuttx/include/nuttx/userspace.h:35,
from nuttx/include/nuttx/mm/mm.h:30,
from nuttx/include/nuttx/kmalloc.h:34,
from nuttx/include/nuttx/lib/lib.h:31,
from nuttx/include/stdio.h:35,
from apps/system/libuv/libuv/include/uv.h:59,
from libuv/src/unix/udp.c:22:
nuttx/include/nuttx/nuttx.h:48: note: this is the location of the previous definition
48 | #define container_of(ptr, type, member) \
|
Signed-off-by: chao an <anchao@lixiang.com>
1.client get the regualtor which is enabled by server, will disable the regualtor.
2.regulator_rpmsg_server_unbind will disable regualtor which maybe used by other client.
3.regulator_rpmsg_server_unbind will be deadloop when the regulator is always_on;
4.regulator_rpmsg_client_destroy does not match server cpu name,may destory by stop other rptun dev
Signed-off-by: dulibo1 <dulibo1@xiaomi.com>
1.Change priv to client or server
2.Allocate memory for name in regulator_rpmsg_get
3.Lock/unlock regulator_list in regulator_rpmsg_server_s
Signed-off-by: Xiang Xiao <xiaoxiang@xiaomi.com>
1.add new intf regulator_set_mode to manual set rehulator lower power mode;
2.when add auto lp desc,the regulator lp mode is controlled by pm framework;
Signed-off-by: dulibo1 <dulibo1@xiaomi.com>
when add supply desc,the regulator is linked to the parent regulator
1.if enable the regualtor, the parent regulator is enabled
2.if disable all child regulator, the parent regualtor is disabled
Signed-off-by: dulibo1 <dulibo1@xiaomi.com>
