Fishwaldo opened a new pull request, #19876:
URL: https://github.com/apache/nuttx/pull/19876
## Summary
Adds `/proc/reset`, which lists every reset line a board's controllers have
and
whether each one is currently asserted or released.
There was no way to see that. `status()` reads one line at a time, and only
for
a caller that already knows its id; nothing else in the interface says how
many
lines a controller has or what any of them resets. During bring up that is
the
question that matters, since a peripheral that appears dead is often just
still
in reset.
The file is rendered from a new optional `get_line` method, under
`CONFIG_RESET_PROCFS`. Every line carries the same `key:value` tokens in the
same order, so the file can be parsed as well as read.
It also fixes an existing hazard in the function it modifies:
`procfs_register()` appends without checking for duplicates, so registering a
controller after all of them had unregistered would have added `/proc/reset`
a
second time. The entry is now claimed once for the lifetime of the system.
The state deliberately stays with `status()`, which already reports it — the
framework calls it, so a controller never supplies the same fact twice.
`get_line` supplies only what the framework cannot derive:
```c
struct reset_lineinfo_s
{
char name[RESET_NAME_MAX]; /* What this line resets */
char extra[RESET_EXTRA_MAX]; /* Controller specific key:value text */
};
```
**Everything is optional.** A controller without `get_line` is listed by name
and a note. Both members may be left empty, and a line then reports by id
alone. `extra` carries whatever the structure has no member for.
Controllers commonly leave gaps in their numbering, so `nlines` in
`struct reset_controller_dev` bounds the ids `get_line` is asked about rather
than counting real lines — for a controller with dense numbering the two are
the same, which is why it is not called `maxid`. Returning `-ENODEV` reports
an
id that names no line, and the renderer skips those, which is what keeps the
listing dense:
```c
static int mychip_getline(FAR struct reset_controller_dev *rcdev,
unsigned int id,
FAR struct reset_lineinfo_s *info)
{
if (id >= nitems(g_mychip_lines) || g_mychip_lines[id].name == NULL)
{
return -ENODEV; /* a gap in the numbering */
}
strlcpy(info->name, g_mychip_lines[id].name, sizeof(info->name));
snprintf(info->extra, sizeof(info->extra), "reg:0x%03x bit:%u",
MYCHIP_RESET_REG(id), MYCHIP_RESET_BIT(id));
return OK;
}
```
This follows the shape of the pinctrl read-back in #19871, so the two procfs
entries agree on how a controller describes itself.
`Documentation/components/drivers/special/reset.rst` had a title and no
content. It now documents the framework: the consumer interface and what
shared and exclusive handles mean, the controller interface and its call
table, the new method, and `/proc/reset`.
## Impact
New feature, off by default. `CONFIG_RESET_PROCFS` depends on
`FS_PROCFS_REGISTER`; with it unset nothing here is compiled.
`struct reset_control_ops` gains one optional member and
`struct reset_controller_dev` gains `nlines`. The only in-tree controller is
`drivers/reset/reset_rpmsg.c`, which is unaffected: it allocates its
controller
with `kmm_zalloc()`, so the new field is zero and the new method NULL, and it
is listed with its note.
No change to the existing operations or their behaviour.
Worth flagging to reviewers: **no in-tree configuration enables
`CONFIG_RESET`**,
so CI will not compile this code. A green run says nothing about it, and the
testing below is the only evidence.
## Testing
Host: macOS 26.5.1 (arm64), `riscv-none-elf-gcc` 15.2.0, Sphinx 6.2.1.
**Build**, since CI cannot: `sim:nsh` with `RESET`, `FS_PROCFS`,
`FS_PROCFS_REGISTER` and `RESET_PROCFS` forced on compiles
`drivers/reset/core.c`
clean; also built with `RESET_PROCFS` off. Documentation builds with no new
warnings.
**Hardware**: ESWIN EIC7700 EVB (EIC7700X, 4 x RV64GC). The consumer is the
EIC7700X CRG reset driver, part of a port being upstreamed separately; this
PR is deliberately independent of it and adds no in-tree user.
```
nsh> cat /proc/reset
eic7700x-crg:
0 noc_nsp state:released reg:0x400 bit:0
16 snoc_aon_a state:released reg:0x400 bit:16
32 gpu_axi state:asserted reg:0x404 bit:0
36 gpu_spu state:asserted reg:0x404 bit:4
64 dsp_axi state:asserted reg:0x408 bit:0
1920 testmux state:released reg:0x4f0 bit:0
1921 spi_slv state:released reg:0x4f0 bit:1
```
Note 16 → 32 → 36 → 64: that controller is a good exercise of the sparse
case,
1628 of its 1952 ids naming nothing, and the gaps are skipped rather than
printed.
Checked on that output:
* **324 lines rendered**, exactly matching the controller's table — every gap
skipped, none of the 1628 empty ids printed
* ids strictly increasing with no duplicate at any read boundary; the file is
many times one read buffer, so this exercises the `pos` accounting across
repeated `read()` calls
* **the `state:` column verified against the hardware**: 107 of the lines
fall
in registers I read independently over JTAG while the board was running,
and
all 107 agree with the register bits (active low, so a set bit reads
`released`) — 0 mismatches
* the asserted lines are plausible on their own terms: the GPU and DSP blocks
read `state:asserted` throughout, and nothing has brought either out of
reset
A controller without `get_line` was checked by removing the method: the
controller is listed with its note and no lines.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
