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

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

[Shivendra Pratap]

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>

[PATCH 1/2] Documentation: ABI: Add sysfs-class-reboot-mode-reboot_modes

[Shivendra Pratap]

Add ABI documentation for /sys/class/reboot-mode/*/reboot_modes, a
read-only sysfs attribute exposing the list of supported reboot-mode
arguments. This file is created by reboot-mode framework and provides a
user-readable interface to query available reboot-mode arguments.

Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Signed-off-by: Shivendra Pratap <shivendra.pratap@oss.qualcomm.com>
---
 .../testing/sysfs-class-reboot-mode-reboot_modes   | 39 ++++++++++++++++++++++
 1 file changed, 39 insertions(+)

diff --git a/Documentation/ABI/testing/sysfs-class-reboot-mode-reboot_modes b/Documentation/ABI/testing/sysfs-class-reboot-mode-reboot_modes
new file mode 100644
index 0000000000000000000000000000000000000000..28280ffe9bf962ef9d2136ea5d7c6aef77c4bd34
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-class-reboot-mode-reboot_modes
@@ -0,0 +1,39 @@
+What:		/sys/class/reboot-mode/<driver>/reboot_modes
+Date:		November 2025
+KernelVersion:	6.18.0-rc5
+Contact:	linux-pm@vger.kernel.org
+		Description:
+		This interface exposes the reboot-mode arguments
+		registered with the reboot-mode framework. It is
+		a read-only interface and provides a space
+		separated list of reboot-mode arguments supported
+		on the current platform.
+		Example:
+		 recovery fastboot bootloader
+
+		The exact sysfs path may vary depending on the
+		name of the driver that registers the arguments.
+		Example:
+		 /sys/class/reboot-mode/nvmem-reboot-mode/reboot_modes
+		 /sys/class/reboot-mode/syscon-reboot-mode/reboot_modes
+		 /sys/class/reboot-mode/qcom-pon/reboot_modes
+
+		The supported arguments can be used by userspace
+		to invoke device reset using the reboot() system
+		call, with the "argument" as string to "*arg"
+		parameter along with LINUX_REBOOT_CMD_RESTART2.
+		Example:
+		 reboot(LINUX_REBOOT_MAGIC1, LINUX_REBOOT_MAGIC2,
+		        LINUX_REBOOT_CMD_RESTART2, "bootloader");
+
+		A driver can expose the supported arguments by
+		registering them with the reboot-mode framework
+		using the property names that follow the
+		mode-<argument> format.
+		Example:
+		 mode-bootloader, mode-recovery.
+
+		This attribute is useful for scripts or initramfs
+		logic that need to programmatically determine
+		which reboot-mode arguments are valid before
+		triggering a reboot.

-- 
2.34.1

Re: [PATCH 1/2] Documentation: ABI: Add sysfs-class-reboot-mode-reboot_modes

[Dmitry Baryshkov]

On Sun, Nov 16, 2025 at 08:49:47PM +0530, Shivendra Pratap wrote:
> Add ABI documentation for /sys/class/reboot-mode/*/reboot_modes, a
> read-only sysfs attribute exposing the list of supported reboot-mode
> arguments. This file is created by reboot-mode framework and provides a
> user-readable interface to query available reboot-mode arguments.
> 
> Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.com>
> Signed-off-by: Shivendra Pratap <shivendra.pratap@oss.qualcomm.com>
> ---
>  .../testing/sysfs-class-reboot-mode-reboot_modes   | 39 ++++++++++++++++++++++
>  1 file changed, 39 insertions(+)
> 
> diff --git a/Documentation/ABI/testing/sysfs-class-reboot-mode-reboot_modes b/Documentation/ABI/testing/sysfs-class-reboot-mode-reboot_modes
> new file mode 100644
> index 0000000000000000000000000000000000000000..28280ffe9bf962ef9d2136ea5d7c6aef77c4bd34
> --- /dev/null
> +++ b/Documentation/ABI/testing/sysfs-class-reboot-mode-reboot_modes
> @@ -0,0 +1,39 @@
> +What:		/sys/class/reboot-mode/<driver>/reboot_modes
> +Date:		November 2025
> +KernelVersion:	6.18.0-rc5
> +Contact:	linux-pm@vger.kernel.org
> +		Description:
> +		This interface exposes the reboot-mode arguments
> +		registered with the reboot-mode framework. It is
> +		a read-only interface and provides a space
> +		separated list of reboot-mode arguments supported
> +		on the current platform.
> +		Example:
> +		 recovery fastboot bootloader
> +
> +		The exact sysfs path may vary depending on the
> +		name of the driver that registers the arguments.
> +		Example:
> +		 /sys/class/reboot-mode/nvmem-reboot-mode/reboot_modes
> +		 /sys/class/reboot-mode/syscon-reboot-mode/reboot_modes
> +		 /sys/class/reboot-mode/qcom-pon/reboot_modes

This part is obvious, isn't it?

> +
> +		The supported arguments can be used by userspace
> +		to invoke device reset using the reboot() system
> +		call, with the "argument" as string to "*arg"
> +		parameter along with LINUX_REBOOT_CMD_RESTART2.
> +		Example:
> +		 reboot(LINUX_REBOOT_MAGIC1, LINUX_REBOOT_MAGIC2,
> +		        LINUX_REBOOT_CMD_RESTART2, "bootloader");

So, does one need to write a tool for invoking reboot with the corerct
set of args? If we are adding a sysfs interface, wouldn't it be logical
to also add another sysfs file, setting the argument?

> +
> +		A driver can expose the supported arguments by
> +		registering them with the reboot-mode framework
> +		using the property names that follow the
> +		mode-<argument> format.
> +		Example:
> +		 mode-bootloader, mode-recovery.
> +
> +		This attribute is useful for scripts or initramfs
> +		logic that need to programmatically determine
> +		which reboot-mode arguments are valid before
> +		triggering a reboot.
> 
> -- 
> 2.34.1
> 

-- 
With best wishes
Dmitry

Re: [PATCH 1/2] Documentation: ABI: Add sysfs-class-reboot-mode-reboot_modes

[Shivendra Pratap]

On 11/16/2025 11:14 PM, Dmitry Baryshkov wrote:
> On Sun, Nov 16, 2025 at 08:49:47PM +0530, Shivendra Pratap wrote:
>> Add ABI documentation for /sys/class/reboot-mode/*/reboot_modes, a
>> read-only sysfs attribute exposing the list of supported reboot-mode
>> arguments. This file is created by reboot-mode framework and provides a
>> user-readable interface to query available reboot-mode arguments.
>>
>> Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.com>
>> Signed-off-by: Shivendra Pratap <shivendra.pratap@oss.qualcomm.com>
>> ---
>>  .../testing/sysfs-class-reboot-mode-reboot_modes   | 39 ++++++++++++++++++++++
>>  1 file changed, 39 insertions(+)
>>
>> diff --git a/Documentation/ABI/testing/sysfs-class-reboot-mode-reboot_modes b/Documentation/ABI/testing/sysfs-class-reboot-mode-reboot_modes
>> new file mode 100644
>> index 0000000000000000000000000000000000000000..28280ffe9bf962ef9d2136ea5d7c6aef77c4bd34
>> --- /dev/null
>> +++ b/Documentation/ABI/testing/sysfs-class-reboot-mode-reboot_modes
>> @@ -0,0 +1,39 @@
>> +What:		/sys/class/reboot-mode/<driver>/reboot_modes
>> +Date:		November 2025
>> +KernelVersion:	6.18.0-rc5
>> +Contact:	linux-pm@vger.kernel.org
>> +		Description:
>> +		This interface exposes the reboot-mode arguments
>> +		registered with the reboot-mode framework. It is
>> +		a read-only interface and provides a space
>> +		separated list of reboot-mode arguments supported
>> +		on the current platform.
>> +		Example:
>> +		 recovery fastboot bootloader
>> +
>> +		The exact sysfs path may vary depending on the
>> +		name of the driver that registers the arguments.
>> +		Example:
>> +		 /sys/class/reboot-mode/nvmem-reboot-mode/reboot_modes
>> +		 /sys/class/reboot-mode/syscon-reboot-mode/reboot_modes
>> +		 /sys/class/reboot-mode/qcom-pon/reboot_modes
> 
> This part is obvious, isn't it?

yes thats correct. Its just added for completeness of the documentation.

> 
>> +
>> +		The supported arguments can be used by userspace
>> +		to invoke device reset using the reboot() system
>> +		call, with the "argument" as string to "*arg"
>> +		parameter along with LINUX_REBOOT_CMD_RESTART2.
>> +		Example:
>> +		 reboot(LINUX_REBOOT_MAGIC1, LINUX_REBOOT_MAGIC2,
>> +		        LINUX_REBOOT_CMD_RESTART2, "bootloader");
> 
> So, does one need to write a tool for invoking reboot with the corerct
> set of args? If we are adding a sysfs interface, wouldn't it be logical
> to also add another sysfs file, setting the argument?

Some of such utilities are already in use and they pass command as an "*arg"
to the reboot SYSCALL.

reboot-mode is currently tied to the reboot SYSCALL - "*arg" being processed as
command. We can open a sysfs for setting the argument - That will be a design
change for reboot-mode and then we need to also decide that if the command
being passes will override the sysfs?

thanks,
Shivendra

Re: [PATCH 1/2] Documentation: ABI: Add sysfs-class-reboot-mode-reboot_modes

[Bjorn Andersson]

On Sun, Nov 16, 2025 at 07:44:24PM +0200, Dmitry Baryshkov wrote:
> On Sun, Nov 16, 2025 at 08:49:47PM +0530, Shivendra Pratap wrote:
> > Add ABI documentation for /sys/class/reboot-mode/*/reboot_modes, a
> > read-only sysfs attribute exposing the list of supported reboot-mode
> > arguments. This file is created by reboot-mode framework and provides a
> > user-readable interface to query available reboot-mode arguments.
> > 
> > Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.com>
> > Signed-off-by: Shivendra Pratap <shivendra.pratap@oss.qualcomm.com>
> > ---
> >  .../testing/sysfs-class-reboot-mode-reboot_modes   | 39 ++++++++++++++++++++++
> >  1 file changed, 39 insertions(+)
> > 
> > diff --git a/Documentation/ABI/testing/sysfs-class-reboot-mode-reboot_modes b/Documentation/ABI/testing/sysfs-class-reboot-mode-reboot_modes
> > new file mode 100644
> > index 0000000000000000000000000000000000000000..28280ffe9bf962ef9d2136ea5d7c6aef77c4bd34
> > --- /dev/null
> > +++ b/Documentation/ABI/testing/sysfs-class-reboot-mode-reboot_modes
> > @@ -0,0 +1,39 @@
> > +What:		/sys/class/reboot-mode/<driver>/reboot_modes
> > +Date:		November 2025
> > +KernelVersion:	6.18.0-rc5
> > +Contact:	linux-pm@vger.kernel.org
> > +		Description:
> > +		This interface exposes the reboot-mode arguments
> > +		registered with the reboot-mode framework. It is
> > +		a read-only interface and provides a space
> > +		separated list of reboot-mode arguments supported
> > +		on the current platform.
> > +		Example:
> > +		 recovery fastboot bootloader
> > +
> > +		The exact sysfs path may vary depending on the
> > +		name of the driver that registers the arguments.
> > +		Example:
> > +		 /sys/class/reboot-mode/nvmem-reboot-mode/reboot_modes
> > +		 /sys/class/reboot-mode/syscon-reboot-mode/reboot_modes
> > +		 /sys/class/reboot-mode/qcom-pon/reboot_modes
> 
> This part is obvious, isn't it?
> 
> > +
> > +		The supported arguments can be used by userspace
> > +		to invoke device reset using the reboot() system
> > +		call, with the "argument" as string to "*arg"
> > +		parameter along with LINUX_REBOOT_CMD_RESTART2.
> > +		Example:
> > +		 reboot(LINUX_REBOOT_MAGIC1, LINUX_REBOOT_MAGIC2,
> > +		        LINUX_REBOOT_CMD_RESTART2, "bootloader");
> 
> So, does one need to write a tool for invoking reboot with the corerct
> set of args?

Here's an implementation of such tool
https://github.com/systemd/systemd/blob/main/src/shared/reboot-util.c#L80

Many other implementations of reboot provides the same.

> If we are adding a sysfs interface, wouldn't it be logical
> to also add another sysfs file, setting the argument?
> 

The inclusion of the example indicates that we need to expose it in an
accessible form, but I don't think we should, as it's already a
widespread standard interface.

As such, I don't think the example adds any value, but it would be
valuable to clarify that this is a standard interface.

Regards,
Bjorn

> > +
> > +		A driver can expose the supported arguments by
> > +		registering them with the reboot-mode framework
> > +		using the property names that follow the
> > +		mode-<argument> format.
> > +		Example:
> > +		 mode-bootloader, mode-recovery.
> > +
> > +		This attribute is useful for scripts or initramfs
> > +		logic that need to programmatically determine
> > +		which reboot-mode arguments are valid before
> > +		triggering a reboot.
> > 
> > -- 
> > 2.34.1
> > 
> 
> -- 
> With best wishes
> Dmitry

Re: [PATCH 1/2] Documentation: ABI: Add sysfs-class-reboot-mode-reboot_modes

[Shivendra Pratap]

On 11/18/2025 2:18 AM, Bjorn Andersson wrote:
> On Sun, Nov 16, 2025 at 07:44:24PM +0200, Dmitry Baryshkov wrote:
>> On Sun, Nov 16, 2025 at 08:49:47PM +0530, Shivendra Pratap wrote:
>>> Add ABI documentation for /sys/class/reboot-mode/*/reboot_modes, a
>>> read-only sysfs attribute exposing the list of supported reboot-mode
>>> arguments. This file is created by reboot-mode framework and provides a
>>> user-readable interface to query available reboot-mode arguments.
>>>
>>> Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.com>
>>> Signed-off-by: Shivendra Pratap <shivendra.pratap@oss.qualcomm.com>
>>> ---
>>>  .../testing/sysfs-class-reboot-mode-reboot_modes   | 39 ++++++++++++++++++++++
>>>  1 file changed, 39 insertions(+)
>>>
>>> diff --git a/Documentation/ABI/testing/sysfs-class-reboot-mode-reboot_modes b/Documentation/ABI/testing/sysfs-class-reboot-mode-reboot_modes
>>> new file mode 100644
>>> index 0000000000000000000000000000000000000000..28280ffe9bf962ef9d2136ea5d7c6aef77c4bd34
>>> --- /dev/null
>>> +++ b/Documentation/ABI/testing/sysfs-class-reboot-mode-reboot_modes
>>> @@ -0,0 +1,39 @@
>>> +What:		/sys/class/reboot-mode/<driver>/reboot_modes
>>> +Date:		November 2025
>>> +KernelVersion:	6.18.0-rc5
>>> +Contact:	linux-pm@vger.kernel.org
>>> +		Description:
>>> +		This interface exposes the reboot-mode arguments
>>> +		registered with the reboot-mode framework. It is
>>> +		a read-only interface and provides a space
>>> +		separated list of reboot-mode arguments supported
>>> +		on the current platform.
>>> +		Example:
>>> +		 recovery fastboot bootloader
>>> +
>>> +		The exact sysfs path may vary depending on the
>>> +		name of the driver that registers the arguments.
>>> +		Example:
>>> +		 /sys/class/reboot-mode/nvmem-reboot-mode/reboot_modes
>>> +		 /sys/class/reboot-mode/syscon-reboot-mode/reboot_modes
>>> +		 /sys/class/reboot-mode/qcom-pon/reboot_modes
>>
>> This part is obvious, isn't it?
>>
>>> +
>>> +		The supported arguments can be used by userspace
>>> +		to invoke device reset using the reboot() system
>>> +		call, with the "argument" as string to "*arg"
>>> +		parameter along with LINUX_REBOOT_CMD_RESTART2.
>>> +		Example:
>>> +		 reboot(LINUX_REBOOT_MAGIC1, LINUX_REBOOT_MAGIC2,
>>> +		        LINUX_REBOOT_CMD_RESTART2, "bootloader");
>>
>> So, does one need to write a tool for invoking reboot with the corerct
>> set of args?
> 
> Here's an implementation of such tool
> https://github.com/systemd/systemd/blob/main/src/shared/reboot-util.c#L80

Should i include this link for an example of existing tools or i just add
add a line saying that such tools are already available?

> 
> Many other implementations of reboot provides the same.
> 
>> If we are adding a sysfs interface, wouldn't it be logical
>> to also add another sysfs file, setting the argument?
>>
> 
> The inclusion of the example indicates that we need to expose it in an
> accessible form, but I don't think we should, as it's already a
> widespread standard interface.
> 
> As such, I don't think the example adds any value, but it would be
> valuable to clarify that this is a standard interface.

ok. Will remove this example of reboot syscall and add a line to
indicate that this is standard interface.

thanks,
Shivendra

Re: [PATCH 1/2] Documentation: ABI: Add sysfs-class-reboot-mode-reboot_modes

[Bjorn Andersson]

On Tue, Nov 18, 2025 at 10:07:51PM +0530, Shivendra Pratap wrote:
> 
> 
> On 11/18/2025 2:18 AM, Bjorn Andersson wrote:
> > On Sun, Nov 16, 2025 at 07:44:24PM +0200, Dmitry Baryshkov wrote:
> >> On Sun, Nov 16, 2025 at 08:49:47PM +0530, Shivendra Pratap wrote:
> >>> Add ABI documentation for /sys/class/reboot-mode/*/reboot_modes, a
> >>> read-only sysfs attribute exposing the list of supported reboot-mode
> >>> arguments. This file is created by reboot-mode framework and provides a
> >>> user-readable interface to query available reboot-mode arguments.
> >>>
> >>> Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.com>
> >>> Signed-off-by: Shivendra Pratap <shivendra.pratap@oss.qualcomm.com>
> >>> ---
> >>>  .../testing/sysfs-class-reboot-mode-reboot_modes   | 39 ++++++++++++++++++++++
> >>>  1 file changed, 39 insertions(+)
> >>>
> >>> diff --git a/Documentation/ABI/testing/sysfs-class-reboot-mode-reboot_modes b/Documentation/ABI/testing/sysfs-class-reboot-mode-reboot_modes
> >>> new file mode 100644
> >>> index 0000000000000000000000000000000000000000..28280ffe9bf962ef9d2136ea5d7c6aef77c4bd34
> >>> --- /dev/null
> >>> +++ b/Documentation/ABI/testing/sysfs-class-reboot-mode-reboot_modes
> >>> @@ -0,0 +1,39 @@
> >>> +What:		/sys/class/reboot-mode/<driver>/reboot_modes
> >>> +Date:		November 2025
> >>> +KernelVersion:	6.18.0-rc5
> >>> +Contact:	linux-pm@vger.kernel.org
> >>> +		Description:
> >>> +		This interface exposes the reboot-mode arguments
> >>> +		registered with the reboot-mode framework. It is
> >>> +		a read-only interface and provides a space
> >>> +		separated list of reboot-mode arguments supported
> >>> +		on the current platform.
> >>> +		Example:
> >>> +		 recovery fastboot bootloader
> >>> +
> >>> +		The exact sysfs path may vary depending on the
> >>> +		name of the driver that registers the arguments.
> >>> +		Example:
> >>> +		 /sys/class/reboot-mode/nvmem-reboot-mode/reboot_modes
> >>> +		 /sys/class/reboot-mode/syscon-reboot-mode/reboot_modes
> >>> +		 /sys/class/reboot-mode/qcom-pon/reboot_modes
> >>
> >> This part is obvious, isn't it?
> >>
> >>> +
> >>> +		The supported arguments can be used by userspace
> >>> +		to invoke device reset using the reboot() system
> >>> +		call, with the "argument" as string to "*arg"
> >>> +		parameter along with LINUX_REBOOT_CMD_RESTART2.
> >>> +		Example:
> >>> +		 reboot(LINUX_REBOOT_MAGIC1, LINUX_REBOOT_MAGIC2,
> >>> +		        LINUX_REBOOT_CMD_RESTART2, "bootloader");
> >>
> >> So, does one need to write a tool for invoking reboot with the corerct
> >> set of args?
> > 
> > Here's an implementation of such tool
> > https://github.com/systemd/systemd/blob/main/src/shared/reboot-util.c#L80
> 
> Should i include this link for an example of existing tools or i just add
> add a line saying that such tools are already available?
> 
> > 
> > Many other implementations of reboot provides the same.
> > 
> >> If we are adding a sysfs interface, wouldn't it be logical
> >> to also add another sysfs file, setting the argument?
> >>
> > 
> > The inclusion of the example indicates that we need to expose it in an
> > accessible form, but I don't think we should, as it's already a
> > widespread standard interface.
> > 
> > As such, I don't think the example adds any value, but it would be
> > valuable to clarify that this is a standard interface.
> 
> ok. Will remove this example of reboot syscall and add a line to
> indicate that this is standard interface.
> 

This sounds good to me.

Thanks,
Bjorn

> thanks,
> Shivendra

[PATCH 2/2] power: reset: reboot-mode: Expose sysfs for registered reboot_modes

[Shivendra Pratap]

Currently, there is no standardized mechanism for userspace to discover
which reboot-modes are supported on a given platform. This limitation
forces tools and scripts to rely on hardcoded assumptions about the
supported reboot-modes.

Create a class 'reboot-mode' and a device under it to expose a sysfs
interface to show the available reboot mode arguments to userspace. Use
the driver_name field of the struct reboot_mode_driver to create the
device.  For device-based drivers, configure the device driver name as
driver_name.

This results in the creation of:
  /sys/class/reboot-mode/<driver>/reboot_modes

This read-only sysfs file will exposes the list of supported reboot
modes arguments provided by the driver, enabling userspace to query the
list of arguments.

Signed-off-by: Shivendra Pratap <shivendra.pratap@oss.qualcomm.com>
---
 drivers/power/reset/reboot-mode.c | 72 +++++++++++++++++++++++++++++++++++++++
 include/linux/reboot-mode.h       |  3 ++
 2 files changed, 75 insertions(+)

diff --git a/drivers/power/reset/reboot-mode.c b/drivers/power/reset/reboot-mode.c
index fba53f638da04655e756b5f8b7d2d666d1379535..062df67735c4818cfeb894941e537f19ea9d4ccb 100644
--- a/drivers/power/reset/reboot-mode.c
+++ b/drivers/power/reset/reboot-mode.c
@@ -7,18 +7,77 @@
 #include <linux/init.h>
 #include <linux/kernel.h>
 #include <linux/module.h>
+#include <linux/mutex.h>
 #include <linux/of.h>
 #include <linux/reboot.h>
 #include <linux/reboot-mode.h>
 
 #define PREFIX "mode-"
 
+static DEFINE_MUTEX(reboot_mode_mutex);
+
 struct mode_info {
 	const char *mode;
 	u32 magic;
 	struct list_head list;
 };
 
+static ssize_t reboot_modes_show(struct device *dev, struct device_attribute *attr, char *buf)
+{
+	struct reboot_mode_driver *reboot;
+	struct mode_info *info;
+	ssize_t size = 0;
+
+	reboot = container_of(dev, struct reboot_mode_driver, reboot_mode_device);
+	if (!reboot)
+		return -ENODATA;
+
+	list_for_each_entry(info, &reboot->head, list)
+		size += sysfs_emit_at(buf, size, "%s ", info->mode);
+
+	if (!size)
+		return -ENODATA;
+
+	return size + sysfs_emit_at(buf, size - 1, "\n");
+}
+static DEVICE_ATTR_RO(reboot_modes);
+
+static struct attribute *reboot_mode_attrs[] = {
+	&dev_attr_reboot_modes.attr,
+	NULL,
+};
+ATTRIBUTE_GROUPS(reboot_mode);
+
+static const struct class reboot_mode_class = {
+	.name = "reboot-mode",
+	.dev_groups = reboot_mode_groups,
+};
+
+static void reboot_mode_device_release(struct device *dev)
+{
+    /* place holder to avoid warning on device_unregister. nothing to free */
+}
+
+static void reboot_mode_create_device(struct reboot_mode_driver *reboot)
+{
+	static bool is_class_registered;
+
+	reboot->reboot_mode_device_registered = false;
+
+	scoped_guard(mutex, &reboot_mode_mutex) {
+		if (!is_class_registered) {
+			if (!class_register(&reboot_mode_class))
+				is_class_registered = true;
+		}
+	}
+
+	reboot->reboot_mode_device.class = &reboot_mode_class;
+	reboot->reboot_mode_device.release = reboot_mode_device_release;
+	dev_set_name(&reboot->reboot_mode_device, reboot->driver_name);
+	if (!device_register(&reboot->reboot_mode_device))
+		reboot->reboot_mode_device_registered = true;
+}
+
 static unsigned int get_reboot_mode_magic(struct reboot_mode_driver *reboot,
 					  const char *cmd)
 {
@@ -78,6 +137,8 @@ int reboot_mode_register(struct reboot_mode_driver *reboot)
 
 	INIT_LIST_HEAD(&reboot->head);
 
+	reboot_mode_create_device(reboot);
+
 	for_each_property_of_node(np, prop) {
 		if (strncmp(prop->name, PREFIX, len))
 			continue;
@@ -119,6 +180,11 @@ int reboot_mode_register(struct reboot_mode_driver *reboot)
 	list_for_each_entry(info, &reboot->head, list)
 		kfree_const(info->mode);
 
+	if (reboot->reboot_mode_device_registered) {
+		device_unregister(&reboot->reboot_mode_device);
+		reboot->reboot_mode_device_registered = false;
+	}
+
 	return ret;
 }
 EXPORT_SYMBOL_GPL(reboot_mode_register);
@@ -136,6 +202,11 @@ int reboot_mode_unregister(struct reboot_mode_driver *reboot)
 	list_for_each_entry(info, &reboot->head, list)
 		kfree_const(info->mode);
 
+	if (reboot->reboot_mode_device_registered) {
+		device_unregister(&reboot->reboot_mode_device);
+		reboot->reboot_mode_device_registered = false;
+	}
+
 	return 0;
 }
 EXPORT_SYMBOL_GPL(reboot_mode_unregister);
@@ -162,6 +233,7 @@ int devm_reboot_mode_register(struct device *dev,
 	if (!dr)
 		return -ENOMEM;
 
+	reboot->driver_name = reboot->dev->driver->name;
 	rc = reboot_mode_register(reboot);
 	if (rc) {
 		devres_free(dr);
diff --git a/include/linux/reboot-mode.h b/include/linux/reboot-mode.h
index 4a2abb38d1d612ec0fdf05eb18c98b210f631b7f..400cfde0e029aef14ff90a11b9d12d0c3ce8dee6 100644
--- a/include/linux/reboot-mode.h
+++ b/include/linux/reboot-mode.h
@@ -5,6 +5,9 @@
 struct reboot_mode_driver {
 	struct device *dev;
 	struct list_head head;
+	const char *driver_name;
+	struct device reboot_mode_device;
+	bool reboot_mode_device_registered;
 	int (*write)(struct reboot_mode_driver *reboot, unsigned int magic);
 	struct notifier_block reboot_notifier;
 };

-- 
2.34.1

Re: [PATCH 2/2] power: reset: reboot-mode: Expose sysfs for registered reboot_modes

[Bartosz Golaszewski]

On Sun, 16 Nov 2025 at 16:20, Shivendra Pratap
<shivendra.pratap@oss.qualcomm.com> wrote:
>
> Currently, there is no standardized mechanism for userspace to discover
> which reboot-modes are supported on a given platform. This limitation
> forces tools and scripts to rely on hardcoded assumptions about the
> supported reboot-modes.
>
> Create a class 'reboot-mode' and a device under it to expose a sysfs
> interface to show the available reboot mode arguments to userspace. Use
> the driver_name field of the struct reboot_mode_driver to create the
> device.  For device-based drivers, configure the device driver name as
> driver_name.
>
> This results in the creation of:
>   /sys/class/reboot-mode/<driver>/reboot_modes
>
> This read-only sysfs file will exposes the list of supported reboot
> modes arguments provided by the driver, enabling userspace to query the
> list of arguments.
>
> Signed-off-by: Shivendra Pratap <shivendra.pratap@oss.qualcomm.com>
> ---
>  drivers/power/reset/reboot-mode.c | 72 +++++++++++++++++++++++++++++++++++++++
>  include/linux/reboot-mode.h       |  3 ++
>  2 files changed, 75 insertions(+)
>
> diff --git a/drivers/power/reset/reboot-mode.c b/drivers/power/reset/reboot-mode.c
> index fba53f638da04655e756b5f8b7d2d666d1379535..062df67735c4818cfeb894941e537f19ea9d4ccb 100644
> --- a/drivers/power/reset/reboot-mode.c
> +++ b/drivers/power/reset/reboot-mode.c
> @@ -7,18 +7,77 @@
>  #include <linux/init.h>
>  #include <linux/kernel.h>
>  #include <linux/module.h>
> +#include <linux/mutex.h>
>  #include <linux/of.h>
>  #include <linux/reboot.h>
>  #include <linux/reboot-mode.h>
>
>  #define PREFIX "mode-"
>
> +static DEFINE_MUTEX(reboot_mode_mutex);
> +
>  struct mode_info {
>         const char *mode;
>         u32 magic;
>         struct list_head list;
>  };
>
> +static ssize_t reboot_modes_show(struct device *dev, struct device_attribute *attr, char *buf)
> +{
> +       struct reboot_mode_driver *reboot;
> +       struct mode_info *info;
> +       ssize_t size = 0;
> +
> +       reboot = container_of(dev, struct reboot_mode_driver, reboot_mode_device);
> +       if (!reboot)
> +               return -ENODATA;
> +
> +       list_for_each_entry(info, &reboot->head, list)
> +               size += sysfs_emit_at(buf, size, "%s ", info->mode);
> +
> +       if (!size)
> +               return -ENODATA;
> +
> +       return size + sysfs_emit_at(buf, size - 1, "\n");
> +}
> +static DEVICE_ATTR_RO(reboot_modes);
> +
> +static struct attribute *reboot_mode_attrs[] = {
> +       &dev_attr_reboot_modes.attr,
> +       NULL,
> +};
> +ATTRIBUTE_GROUPS(reboot_mode);
> +
> +static const struct class reboot_mode_class = {
> +       .name = "reboot-mode",
> +       .dev_groups = reboot_mode_groups,
> +};
> +
> +static void reboot_mode_device_release(struct device *dev)
> +{
> +    /* place holder to avoid warning on device_unregister. nothing to free */
> +}
> +
> +static void reboot_mode_create_device(struct reboot_mode_driver *reboot)
> +{
> +       static bool is_class_registered;
> +
> +       reboot->reboot_mode_device_registered = false;
> +
> +       scoped_guard(mutex, &reboot_mode_mutex) {
> +               if (!is_class_registered) {
> +                       if (!class_register(&reboot_mode_class))
> +                               is_class_registered = true;
> +               }
> +       }

This could be achieved with DO_ONCE() but you still haven't explained
why this needs to be done here. Why not in the module's
subsys_initcall()? As of now, the class will not appear in sysfs until
the first device is registered which isn't a very common behavior.

Bart

> +
> +       reboot->reboot_mode_device.class = &reboot_mode_class;
> +       reboot->reboot_mode_device.release = reboot_mode_device_release;
> +       dev_set_name(&reboot->reboot_mode_device, reboot->driver_name);
> +       if (!device_register(&reboot->reboot_mode_device))
> +               reboot->reboot_mode_device_registered = true;
> +}
> +
>  static unsigned int get_reboot_mode_magic(struct reboot_mode_driver *reboot,
>                                           const char *cmd)
>  {
> @@ -78,6 +137,8 @@ int reboot_mode_register(struct reboot_mode_driver *reboot)
>
>         INIT_LIST_HEAD(&reboot->head);
>
> +       reboot_mode_create_device(reboot);
> +
>         for_each_property_of_node(np, prop) {
>                 if (strncmp(prop->name, PREFIX, len))
>                         continue;
> @@ -119,6 +180,11 @@ int reboot_mode_register(struct reboot_mode_driver *reboot)
>         list_for_each_entry(info, &reboot->head, list)
>                 kfree_const(info->mode);
>
> +       if (reboot->reboot_mode_device_registered) {
> +               device_unregister(&reboot->reboot_mode_device);
> +               reboot->reboot_mode_device_registered = false;
> +       }
> +
>         return ret;
>  }
>  EXPORT_SYMBOL_GPL(reboot_mode_register);
> @@ -136,6 +202,11 @@ int reboot_mode_unregister(struct reboot_mode_driver *reboot)
>         list_for_each_entry(info, &reboot->head, list)
>                 kfree_const(info->mode);
>
> +       if (reboot->reboot_mode_device_registered) {
> +               device_unregister(&reboot->reboot_mode_device);
> +               reboot->reboot_mode_device_registered = false;
> +       }
> +
>         return 0;
>  }
>  EXPORT_SYMBOL_GPL(reboot_mode_unregister);
> @@ -162,6 +233,7 @@ int devm_reboot_mode_register(struct device *dev,
>         if (!dr)
>                 return -ENOMEM;
>
> +       reboot->driver_name = reboot->dev->driver->name;
>         rc = reboot_mode_register(reboot);
>         if (rc) {
>                 devres_free(dr);
> diff --git a/include/linux/reboot-mode.h b/include/linux/reboot-mode.h
> index 4a2abb38d1d612ec0fdf05eb18c98b210f631b7f..400cfde0e029aef14ff90a11b9d12d0c3ce8dee6 100644
> --- a/include/linux/reboot-mode.h
> +++ b/include/linux/reboot-mode.h
> @@ -5,6 +5,9 @@
>  struct reboot_mode_driver {
>         struct device *dev;
>         struct list_head head;
> +       const char *driver_name;
> +       struct device reboot_mode_device;
> +       bool reboot_mode_device_registered;
>         int (*write)(struct reboot_mode_driver *reboot, unsigned int magic);
>         struct notifier_block reboot_notifier;
>  };
>
> --
> 2.34.1
>

Re: [PATCH 2/2] power: reset: reboot-mode: Expose sysfs for registered reboot_modes

[Shivendra Pratap]

On 11/17/2025 6:55 PM, Bartosz Golaszewski wrote:
> On Sun, 16 Nov 2025 at 16:20, Shivendra Pratap
> <shivendra.pratap@oss.qualcomm.com> wrote:
>>
>> Currently, there is no standardized mechanism for userspace to discover
>> which reboot-modes are supported on a given platform. This limitation
>> forces tools and scripts to rely on hardcoded assumptions about the
>> supported reboot-modes.
>>
>> Create a class 'reboot-mode' and a device under it to expose a sysfs
>> interface to show the available reboot mode arguments to userspace. Use
>> the driver_name field of the struct reboot_mode_driver to create the
>> device.  For device-based drivers, configure the device driver name as
>> driver_name.
>>
>> This results in the creation of:
>>   /sys/class/reboot-mode/<driver>/reboot_modes
>>
>> This read-only sysfs file will exposes the list of supported reboot
>> modes arguments provided by the driver, enabling userspace to query the
>> list of arguments.
>>
>> Signed-off-by: Shivendra Pratap <shivendra.pratap@oss.qualcomm.com>
>> ---
>>  drivers/power/reset/reboot-mode.c | 72 +++++++++++++++++++++++++++++++++++++++
>>  include/linux/reboot-mode.h       |  3 ++
>>  2 files changed, 75 insertions(+)
>>
>> diff --git a/drivers/power/reset/reboot-mode.c b/drivers/power/reset/reboot-mode.c
>> index fba53f638da04655e756b5f8b7d2d666d1379535..062df67735c4818cfeb894941e537f19ea9d4ccb 100644
>> --- a/drivers/power/reset/reboot-mode.c
>> +++ b/drivers/power/reset/reboot-mode.c
>> @@ -7,18 +7,77 @@
>>  #include <linux/init.h>
>>  #include <linux/kernel.h>
>>  #include <linux/module.h>
>> +#include <linux/mutex.h>
>>  #include <linux/of.h>
>>  #include <linux/reboot.h>
>>  #include <linux/reboot-mode.h>
>>
>>  #define PREFIX "mode-"
>>
>> +static DEFINE_MUTEX(reboot_mode_mutex);
>> +
>>  struct mode_info {
>>         const char *mode;
>>         u32 magic;
>>         struct list_head list;
>>  };
>>
>> +static ssize_t reboot_modes_show(struct device *dev, struct device_attribute *attr, char *buf)
>> +{
>> +       struct reboot_mode_driver *reboot;
>> +       struct mode_info *info;
>> +       ssize_t size = 0;
>> +
>> +       reboot = container_of(dev, struct reboot_mode_driver, reboot_mode_device);
>> +       if (!reboot)
>> +               return -ENODATA;
>> +
>> +       list_for_each_entry(info, &reboot->head, list)
>> +               size += sysfs_emit_at(buf, size, "%s ", info->mode);
>> +
>> +       if (!size)
>> +               return -ENODATA;
>> +
>> +       return size + sysfs_emit_at(buf, size - 1, "\n");
>> +}
>> +static DEVICE_ATTR_RO(reboot_modes);
>> +
>> +static struct attribute *reboot_mode_attrs[] = {
>> +       &dev_attr_reboot_modes.attr,
>> +       NULL,
>> +};
>> +ATTRIBUTE_GROUPS(reboot_mode);
>> +
>> +static const struct class reboot_mode_class = {
>> +       .name = "reboot-mode",
>> +       .dev_groups = reboot_mode_groups,
>> +};
>> +
>> +static void reboot_mode_device_release(struct device *dev)
>> +{
>> +    /* place holder to avoid warning on device_unregister. nothing to free */
>> +}
>> +
>> +static void reboot_mode_create_device(struct reboot_mode_driver *reboot)
>> +{
>> +       static bool is_class_registered;
>> +
>> +       reboot->reboot_mode_device_registered = false;
>> +
>> +       scoped_guard(mutex, &reboot_mode_mutex) {
>> +               if (!is_class_registered) {
>> +                       if (!class_register(&reboot_mode_class))
>> +                               is_class_registered = true;
>> +               }
>> +       }
> 
> This could be achieved with DO_ONCE() but you still haven't explained
> why this needs to be done here. Why not in the module's
> subsys_initcall()? As of now, the class will not appear in sysfs until
> the first device is registered which isn't a very common behavior.

sure will add a subsys_initcall() and add it there.

thanks,
Shivendra

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

[Bartosz Golaszewski]

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>
>

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

[Shivendra Pratap]

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

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

[Bartosz Golaszewski]

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

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

[Shivendra Pratap]

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