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.
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature