[PATCH v23 03/13] power: reset: reboot-mode: Add support for predefined reboot modes
Shivendra Pratap
shivendra.pratap at oss.qualcomm.com
Thu Jul 23 06:09:11 PDT 2026
On 22-07-2026 13:10, Pavan Kondeti wrote:
> On Tue, Jul 14, 2026 at 10:46:31PM +0530, Shivendra Pratap wrote:
>> reboot-mode based drivers can define a reboot-mode by adding it under
>> the reboot-mode node in device tree. This limits such drivers, to define
>> any predefined reboot-modes statically within the driver and creates a
>> dependency on device-tree.
>>
>> Extend the reboot-mode framework to handle predefined modes alongside
>> those defined in device tree. Drivers can now define their own
>> reboot-modes and register them via the framework. A centralized init
>> call has been added to the reboot-mode framework and adopted by
>> existing drivers. This ensures driver state is initialized together
>> with predefined modes.
>>
>> Signed-off-by: Shivendra Pratap <shivendra.pratap at oss.qualcomm.com>
>> @@ -195,35 +264,17 @@ int reboot_mode_register(struct reboot_mode_driver *reboot)
>> continue;
>> }
>>
>> - info = kzalloc(sizeof(*info), GFP_KERNEL);
>> - if (!info) {
>> - ret = -ENOMEM;
>> - goto error;
>> - }
>> -
>> - if (!memchr_inv(magic, 0, count * sizeof(u32))) {
>> - pr_debug("reboot mode %s with zero magic values\n", prop->name);
>> - info->count = -1;
>> - } else {
>> - memcpy(info->magic, magic, count * sizeof(u32));
>> - info->count = count;
>> - }
>> -
>> - info->mode = kstrdup_const(prop->name + len, GFP_KERNEL);
>> - if (!info->mode) {
>> - ret = -ENOMEM;
>> - goto error;
>> - } else if (info->mode[0] == '\0') {
>> - kfree_const(info->mode);
>> - ret = -EINVAL;
>> - pr_err("invalid mode name(%s): too short!\n", prop->name);
>> + info = reboot_mode_create_info(prop->name + len, magic, count);
>> + if (IS_ERR(info)) {
>> + ret = PTR_ERR(info);
>> goto error;
>> }
>>
>> list_add_tail(&info->list, &reboot->head);
>> - info = NULL;
>> }
>>
>> +predefined_modes:
>> + list_splice_tail_init(&reboot->predefined_modes, &reboot->head);
>> reboot->reboot_notifier.notifier_call = reboot_mode_notify;
>> register_reboot_notifier(&reboot->reboot_notifier);
>>
>
> This splice here makes me ask why we need separate API for registering
> pre-defined reboot modes? why not extend `struct reboot_mode_driver` to
> pass on the pre-defined modes and let `reboot_mode_register()` take care
> of both OF & pre-defined modes.
so something like a struct reboot_mode_driver should have a member
with list of predefined_modes and this member will be owned by calling
driver?
>
> The semantics of `reboot_mode_reset_predefined_modes()` is very
> confusing. It is not clear if any client driver needs to really call
> before unregistering? The unregister it self is cleaning up these
> pre-defined modes since they are spliced.
sure can try to align this using above approach.
thanks,
Shivendra
More information about the linux-arm-kernel
mailing list