[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1c2963ff-fa1a-7e28-62bc-51bd2f6f3f5a@oss.qualcomm.com>
Date: Mon, 17 Nov 2025 23:22:21 +0530
From: Shivendra Pratap <shivendra.pratap@....qualcomm.com>
To: Bartosz Golaszewski <bartosz.golaszewski@...aro.org>
Cc: Sebastian Reichel <sre@...nel.org>,
Bjorn Andersson
<andersson@...nel.org>, linux-kernel@...r.kernel.org,
linux-arm-msm@...r.kernel.org, linux-pm@...r.kernel.org
Subject: Re: [PATCH 2/2] power: reset: reboot-mode: Expose sysfs for
registered reboot_modes
On 11/17/2025 6:55 PM, Bartosz Golaszewski wrote:
> On Sun, 16 Nov 2025 at 16:20, Shivendra Pratap
> <shivendra.pratap@....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@....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
Powered by blists - more mailing lists