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
