[PATCH v2 0/4] Implement vendor resets for PSCI SYSTEM_RESET2

Elliot Berman quic_eberman at quicinc.com
Wed Apr 17 14:54:41 PDT 2024


On Tue, Apr 16, 2024 at 10:35:22AM +0100, Sudeep Holla wrote:
> On Sun, Apr 14, 2024 at 12:30:23PM -0700, Elliot Berman wrote:
> > The PSCI SYSTEM_RESET2 call allows vendor firmware to define additional
> > reset types which could be mapped to the reboot argument.
> >
> > Setting up reboot on Qualcomm devices can be inconsistent from chipset
> > to chipset.
> 
> That doesn't sound good. Do you mean PSCI SYSTEM_RESET doesn't work as
> expected ? Does it mean it is not conformant to the specification ?
> 

I was motivating the reason for using SYSTEM_RESET2. How to set the PMIC
register and IMEM cookie can change between chipsets. Using
SYSTEM_RESET2 alows us to abstract how to perform the reset.

> > Generally, there is a PMIC register that gets written to
> > decide the reboot type. There is also sometimes a cookie that can be
> > written to indicate that the bootloader should behave differently than a
> > regular boot. These knobs evolve over product generations and require
> > more drivers. Qualcomm firmwares are beginning to expose vendor
> > SYSTEM_RESET2 types to simplify driver requirements from Linux.
> >
> 
> Why can't this be fully userspace driven ? What is the need to keep the
> cookie in the DT ?

As Dmitry pointed out, this information isn't discoverable. I suppose
we could technically use bootconfig or kernel command-line to convey the
map although I think devicetree is the right spot for this mapping.

- Other vendor-specific bits for PSCI are described in the devicetree.
  One example is the suspend param (e.g. the StateID) for cpu idle
  states.
- Describing firmware bits in the DT isn't unprecedented, and putting
  this information outside the DT means that other OSes (besides Linux)
  need their own way to convey this information.
- PSCI would be the odd one out that reboot mode map is not described in
  DT. Other reboot-mode drivers specify the mapping in the DT. Userspace
  that runs with firmware that support vendor reset2 need to make sure
  they can configure the mapping early enough.

Thanks,
Elliot




More information about the linux-arm-kernel mailing list