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

From: Florian Fainelli
Date: Wed Apr 17 2024 - 13:50:30 EST


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