On Wed, Apr 17, 2024 at 10:50:07AM -0700, Florian Fainelli wrote: > 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. > Yes that was my thought when I wrote the email. But since I have looked at existing bindings and support in the kernel in little more detail I would say. So I am not sure what would be the better choice for PSCI SYSTEM_RESET2 especially when there is some ground support to build. So I am open for alternatives including this approach. -- Regards, Sudeep
