On 4/16/24 02:35, 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 ?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 ?
Using the second example in the Device Tree: mode-bootloader = <1 2>;are you suggesting that within psci_vendor_sys_reset2() we would look at the data argument and assume that we have something like this in memory:
const char *cmd = data; cmd[] = "bootloader 2"where "bootloader" is the reboot command, and "2" is the cookie? From an util-linux, busybox, toybox, etc. we would have to concatenate those arguments with a space, but I suppose that would be doable.
For the use cases that I am after we did not have a need for the cookie, so I admit I did not think too much about it.
-- Florian
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature
