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

[Lorenzo Pieralisi]

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