On Fri, Apr 19, 2024 at 01:38:47PM +0100, Sudeep Holla wrote: > 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. If we can't go with the DT approach, my preference would be to go with a bootconfig and sysfs for controlling the mappings, although I don't think userspace need/should control the mappings of cmd -> cookies. I wanted to check if you are okay with proceeding with the reboot-mode DT bindings approach unless we have some other better standard? If yes, do you have any preference based on Konrad's comment [1]? I can send out v3 with the couple comments from Dmitry and Krzysztof's addressed. Thanks, Elliot [1]: https://lore.kernel.org/all/20240419123847.ica22nft3sejqnm7@bogus/
