Re: [PATCH v23 03/13] power: reset: reboot-mode: Add support for predefined reboot modes
Shivendra Pratap <[email protected]> Thu, 23 Jul 2026 18:39:11 +0530
| Newsgroups | dev.linux.lists.mfd,org.infradead.lists.linux-arm-kernel,org.kernel.vger.linux-arm-msm,org.kernel.vger.linux-devicetree,org.kernel.vger.linux-kernel,org.kernel.vger.linux-pm |
|---|---|
| Message-ID | <[email protected]> |
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 <[email protected]> >> @@ -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