Re: [PATCH v17 07/12] firmware: psci: Implement vendor-specific resets as reboot-mode

Lorenzo Pieralisi
2025-11-19T09:38:04Z

On Tue, Nov 18, 2025 at 11:11:33PM +0530, Shivendra Pratap wrote:

[...]

> > Yes this could be a potential way forward but that's decoupled from the
> > options below. If we take this route PSCI maintainers should be added
> > as maintainers for this reboot mode driver.
>
> you mean the new psci_reset driver? yes. Maintainer would be PSCI maintainer,
> if we create a new psci_reset reboot mode driver.

Yes.

> >> - struct with pre-built psci reset_types - (warm, soft, cold). Currently
> >> only two modes supported, anything other than warm/soft defaults to cold.
> >> - vendor resets to be added as per vendor choice, inside psci device tree(SOC specific).
> >> - psci_reset registers with reboot-mode for registering vendor resets. Here, we
> >> have a problem, the pre-built psci reset_types - (warm, soft, cold) cannot be added via
> >> reboot-mode framework.
> >
> > Why ?
>
> If we want the new psci_reset to take the reboot-mode framework route, is it ok to
> add default modes (warm, cold) in the device tree?
> If not, then the design of reboot-mode framework(power:reset:reboot-mode.c) needs to be
> further changed to equip this new feature.

Well, yes, all it needs to do is allowing prepopulated reboot modes on top
of which DT based ones are added.

I don't see any point in adding properties to the DT node to provide
information we can already probe.

> If new psci_reset driver move away from reboot-mode framework(power:reset:reboot-mode.c), the driver
> can have its own design, its own sysfs interface and maintained under psci Maintainer.
>
> >
> >> Should the new psci_reset driver, move away from reboot-mode
> >> framework as-well? And define its own parsing logic for psci_reset_types,
> >> and have its own restart_notifier instead of reboot_notifier?
> >
> > No. As I said earlier, I think it makes sense to allow user space to
> > select _all_ PSCI reset types - architected and vendor specific in
> > a single reboot mode driver.
> >
> > I believe that we must be able to have two well defined ways for
> > issuing resets:
> >
> > - one based on reboot mode driver
> > - one based on reboot_mode variable interface
>
> So may be in more details-
> user space issues - reboot cold
> -> go for psci_reset (as psci_sysrest2 does not has cold reset?)
> user space issues - reboot warm or a vendor_reset
> -> if psci_sysreset2 is supported - call psci_sysreset2 with required params.
> -> else
> -> go for psci_reset COLD
>
> user space issues - reboot (no commands) or a panic_in_progress
> -> fallback to reboot_mode
> -> if (reboot_mode == WARM and psci_sysreset2 is supported )
> -> call psci_sysreset2 (ARCH WARM RESET)
> -> else
> -> go for psci_reset COLD
>
>
> And we want to do this in two conditional statements in firmware:psci: psci_sys_reset
> function?
> Or am i not getting the point here?

You are getting the point.

Thanks,
Lorenzo

> thanks,
> Shivendra
>
> >
> > Does this make sense everyone ? I don't know the history behind
> > reboot_mode and the reboot mode driver framework I am just stating
> > what I think makes sense to do for PSCI.
> >
> > Thanks,
> > Lorenzo
> >
> >> - If new psci_reset driver move away from reboot-mode, we can get rid of the panic_notifier
> >> added in the psci code. Else, we may still need the panic_notifier for any kernel panic
> >> that occurs between reboot_notifier and restart_notifier?
> >> - psci driver will export a function which will be called externally to set the current
> >> psci reset_type.
> >> - psci_sys_reset in psci driver should remove the check on reboot_mode. It will default to
> >> cold reset (for the reason the current kernel defaults to cold reset in psci.)
> >> example change in psci_sys_reset:
> >> if(psci_system_reset2_supported && <psci_reset_new_struct_var> != cold)
> >> psci_sys_reset2(AS PER PARAMS FROM new psci_reset driver)
> >> else
> >> psci_sys_reset(COLD RESET)
> >>
> >> thanks,
> >> Shivendra