[PATCH v19 0/2] reboot-mode: Expose sysfs for registered reboot modes

From: Shivendra Pratap

Date: Sat Nov 22 2025 - 13:06:00 EST


The reboot-mode framework provides infrastructure for drivers that want
to implement a userspace reboot command interface. However, there is
currently no standardized way for userspace to discover the list of
supported commands at runtime. This series introduces a sysfs interface
in the reboot-mode framework to expose the list of supported reboot-mode
commands to userspace. This will enable userspace tools to query
available reboot modes using the sysfs interface.

Example:
cat /sys/class/reboot-mode/<driver-name>/reboot_modes

The series consists of two patches:
1. power: reset: reboot-mode: Expose sysfs for registered reboot_modes
2. Documentation: ABI: Add sysfs-class-reboot-mode-reboot_modes

These patches were previously being reviewed as part of “vendor resets
for PSCI SYSTEM_RESET2”, until v17. Following the suggestions from
Bjorn, the reboot-mode sysfs patches have been split into a separate
series here, for focused discussions and better alignment.

Previous discussion on these patches:
https://lore.kernel.org/all/20251109-arm-psci-system_reset2-vendor-reboots-v17-5-46e085bca4cc@xxxxxxxxxxxxxxxx/
https://lore.kernel.org/all/20251109-arm-psci-system_reset2-vendor-reboots-v17-4-46e085bca4cc@xxxxxxxxxxxxxxxx/

Signed-off-by: Shivendra Pratap <shivendra.pratap@xxxxxxxxxxxxxxxx>

Changes in v19:
By Bart
- Added subsys_initcall and moved class_register to initcall.

By Bjorn
- Remove example of reboot SYSCALL from ABI documentation and mention
about this being standard interface.

For Alignment
- Added module_init/module_exit, in case reboot-mode is compiled as module.
- Call class_unregister on module_exit.
- Remove mutex lock on class_register as its not needed now.
- Added a static bool reboot_mode_class_registered, to save the status of
class registration.
- Rename reboot_mode_create_device to reboot_mode_register_device.
- Removed class_register as its moved to initcall.
- Version correction for split series: Previous changed to v18.
- Corrected Typo in Bjorn's Name in last change history.
- Link to v18: https://lore.kernel.org/r/20251116-next-15nov_expose_sysfs-v1-0-3b7880e5b40e@xxxxxxxxxxxxxxxx
- *v18 was sent as v1 in last post.

Changes in v18:
By Bjorn
- class is made static const and moved on the stack and registered
using class_register.
- Renamed name of class variable from rb_class to reboot_mode_class –
Bart/ Bjorn
- Renamed function name to prefix reboot_mode* to better align naming
convention in reboot-mode.
- Changed reboot_mode_device as static in reboot struct and registered
using device_register.
- Used dev_groups, instead of creating the sysfs attr file manually.
- Continued the reboot-mode registration even if the sysfs creation
fails at reboot_mode_create_device.
- Used container of dev in show_reboot_modes to get the structure
pointer of reboot.

By Bart
-Synchronize class registration, as there may be race in this lazy
class_register.
-Remove inversion kind of logic and align the return path of
show_reboot_modes

Other changes
- reboot_dev is renamed to reboot_mode_device to align the naming
conventions.
- Keep a check on status of device_register with bool flag as
device_unregister should be called only if the registration was
successful.
- Add a dummy function reboot_mode_device_release to avoid warn in
driver unload path.
- Date and version change in ABI documentation.
Link to v17:
https://lore.kernel.org/all/20251109-arm-psci-system_reset2-vendor-reboots-v17-0-46e085bca4cc@xxxxxxxxxxxxxxxx

---
---
Shivendra Pratap (2):
Documentation: ABI: Add sysfs-class-reboot-mode-reboot_modes
power: reset: reboot-mode: Expose sysfs for registered reboot_modes

.../testing/sysfs-class-reboot-mode-reboot_modes | 36 +++++++++
drivers/power/reset/reboot-mode.c | 86 ++++++++++++++++++++++
include/linux/reboot-mode.h | 3 +
3 files changed, 125 insertions(+)
---
base-commit: 0f2995693867bfb26197b117cd55624ddc57582f
change-id: 20251116-next-15nov_expose_sysfs-c0dbcf0d59da

Best regards,
--
Shivendra Pratap <shivendra.pratap@xxxxxxxxxxxxxxxx>