.../testing/sysfs-class-reboot-mode-reboot_modes | 39 ++++++++++++ drivers/power/reset/reboot-mode.c | 72 ++++++++++++++++++++++ include/linux/reboot-mode.h | 3 + 3 files changed, 114 insertions(+)
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@oss.qualcomm.com/
https://lore.kernel.org/all/20251109-arm-psci-system_reset2-vendor-reboots-v17-4-46e085bca4cc@oss.qualcomm.com/
Signed-off-by: Shivendra Pratap <shivendra.pratap@oss.qualcomm.com>
Changes from previous version:
By Bjyon
- 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/ Bjyon
- 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 previous series:
https://lore.kernel.org/all/20251109-arm-psci-system_reset2-vendor-reboots-v17-0-46e085bca4cc@oss.qualcomm.com
---
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 | 39 ++++++++++++
drivers/power/reset/reboot-mode.c | 72 ++++++++++++++++++++++
include/linux/reboot-mode.h | 3 +
3 files changed, 114 insertions(+)
---
base-commit: 0f2995693867bfb26197b117cd55624ddc57582f
change-id: 20251116-next-15nov_expose_sysfs-c0dbcf0d59da
Best regards,
--
Shivendra Pratap <shivendra.pratap@oss.qualcomm.com>
On Sun, 16 Nov 2025 at 16:20, Shivendra Pratap <shivendra.pratap@oss.qualcomm.com> wrote: > > 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@oss.qualcomm.com/ > https://lore.kernel.org/all/20251109-arm-psci-system_reset2-vendor-reboots-v17-4-46e085bca4cc@oss.qualcomm.com/ > When doing a split like this, please keep the versioning going. This should be v18. Bart > Signed-off-by: Shivendra Pratap <shivendra.pratap@oss.qualcomm.com> > > Changes from previous version: > By Bjyon > - 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/ Bjyon > - 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 previous series: > https://lore.kernel.org/all/20251109-arm-psci-system_reset2-vendor-reboots-v17-0-46e085bca4cc@oss.qualcomm.com > > --- > 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 | 39 ++++++++++++ > drivers/power/reset/reboot-mode.c | 72 ++++++++++++++++++++++ > include/linux/reboot-mode.h | 3 + > 3 files changed, 114 insertions(+) > --- > base-commit: 0f2995693867bfb26197b117cd55624ddc57582f > change-id: 20251116-next-15nov_expose_sysfs-c0dbcf0d59da > > Best regards, > -- > Shivendra Pratap <shivendra.pratap@oss.qualcomm.com> >
On 11/17/2025 6:33 PM, Bartosz Golaszewski wrote: > On Sun, 16 Nov 2025 at 16:20, Shivendra Pratap > <shivendra.pratap@oss.qualcomm.com> wrote: >> >> 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@oss.qualcomm.com/ >> https://lore.kernel.org/all/20251109-arm-psci-system_reset2-vendor-reboots-v17-4-46e085bca4cc@oss.qualcomm.com/ >> > > When doing a split like this, please keep the versioning going. This > should be v18. Focus of that original series was "Implementing vendor resets for PSCI SYSTEM_RESET2". These two patches have been split out of that series. The original series will still continue to its next version(v18) after addressing all other reviews. So i thought that these two patches can be split out to v1? thanks, Shivendra
On Mon, 17 Nov 2025 at 19:05, Shivendra Pratap <shivendra.pratap@oss.qualcomm.com> wrote: > > > > On 11/17/2025 6:33 PM, Bartosz Golaszewski wrote: > > On Sun, 16 Nov 2025 at 16:20, Shivendra Pratap > > <shivendra.pratap@oss.qualcomm.com> wrote: > >> > >> 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@oss.qualcomm.com/ > >> https://lore.kernel.org/all/20251109-arm-psci-system_reset2-vendor-reboots-v17-4-46e085bca4cc@oss.qualcomm.com/ > >> > > > > When doing a split like this, please keep the versioning going. This > > should be v18. > > Focus of that original series was "Implementing vendor resets for PSCI SYSTEM_RESET2". > These two patches have been split out of that series. The original series will > still continue to its next version(v18) after addressing all other reviews. > So i thought that these two patches can be split out to v1? > No, they both continue at v18 so that the origin of this smaller series is contained. Bartosz
On 11/18/2025 3:30 PM, Bartosz Golaszewski wrote: > On Mon, 17 Nov 2025 at 19:05, Shivendra Pratap > <shivendra.pratap@oss.qualcomm.com> wrote: >> >> >> >> On 11/17/2025 6:33 PM, Bartosz Golaszewski wrote: >>> On Sun, 16 Nov 2025 at 16:20, Shivendra Pratap >>> <shivendra.pratap@oss.qualcomm.com> wrote: >>>> >>>> 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@oss.qualcomm.com/ >>>> https://lore.kernel.org/all/20251109-arm-psci-system_reset2-vendor-reboots-v17-4-46e085bca4cc@oss.qualcomm.com/ >>>> >>> >>> When doing a split like this, please keep the versioning going. This >>> should be v18. >> >> Focus of that original series was "Implementing vendor resets for PSCI SYSTEM_RESET2". >> These two patches have been split out of that series. The original series will >> still continue to its next version(v18) after addressing all other reviews. >> So i thought that these two patches can be split out to v1? >> > > No, they both continue at v18 so that the origin of this smaller > series is contained. sure. I will resend this patch as v18, taking care of current comments as-well. thanks, Shivendra
© 2016 - 2026 Red Hat, Inc.