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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 4/17/24 14:54, Elliot Berman wrote:
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.

FWIW, I read Sudeep's response as being specifically inquiring about the 'cookie' parameter, do you see a need for that to be in described in the DT or could that just be an user-space parameter that is conveyed through the reboot system call?
--
Florian

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature


[Index of Archives]     [Device Tree Compilter]     [Device Tree Spec]     [Linux Driver Backports]     [Video for Linux]     [Linux USB Devel]     [Linux PCI Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Yosemite Backpacking]


  Powered by Linux