[PATCH v12 0/8] Implement vendor resets for PSCI SYSTEM_RESET2

[Krzysztof Kozlowski]

On 24/07/2025 14:24, Shivendra Pratap wrote:
> 
> 
> On 7/24/2025 5:46 AM, Florian Fainelli wrote:
>> On 7/21/25 11:28, Shivendra Pratap wrote:
>>> The PSCI SYSTEM_RESET2 call allows vendor firmware to define
>>> additional reset types which could be mapped to the reboot
>>> argument.
>>>
>>> User-space should be able to reboot a device into different
>>> operational boot-states supported by underlying bootloader and
>>> firmware. Generally, some HW registers need to be written, based
>>> on which the bootloader and firmware decide the next boot state
>>> of device, after the reset. For example, a requirement on
>>> Qualcomm platforms may state that reboot with "bootloader"
>>> command, should reboot the device into bootloader flashing mode
>>> and reboot with “edl” command, should reboot the device into an
>>> Emergency flashing mode.  Setting up such reboots on Qualcomm
>>> devices can be inconsistent across SoC platforms and may require
>>> setting different HW registers, where some of these registers may
>>> not be accessible to HLOS. These knobs evolve over product
>>> generations and require more drivers.  PSCI defines a
>>> vendor-specific reset in SYSTEM_RESET2 spec, which enables the
>>> firmware to take care of underlying setting for any such
>>> supported vendor-specific reboot. Qualcomm firmwares are
>>> beginning to support and expose PSCI SYSTEM_RESET2
>>> vendor-specific reset types to simplify driver requirements from
>>> Linux. With such support added in the firmware, we now need a
>>> Linux interface which can make use of the firmware calls for PSCI
>>> vendor-specific resets. This will align such reboot requirement
>>> across platforms and vendors.
>>>
>>> The current psci driver supports two types of resets –
>>> SYSTEM_RESET2 Arch warm-reset and SYSTEM_RESET cold-reset. The
>>> patchset introduces the PSCI SYSTEM_RESET2 vendor-specific reset
>>> into the reset path of the psci driver and aligns it to work with
>>> reboot system call - LINUX_REBOOT_CMD_RESTART2, when used along
>>> with a supported string-based command in “*arg”.
>>>
>>> The patchset uses reboot-mode based commands, to define the
>>> supported vendor reset-types commands in psci device tree node
>>> and registers these commands with the reboot-mode framework.
>>>
>>> The PSCI vendor-specific reset takes two arguments, being,
>>> reset_type and cookie as defined by the spec. To accommodate this
>>> requirement, enhance the reboot-mode framework to support two
>>> 32-bit arguments by switching to 64-bit magic values.
>>>
>>> Along this line, the patchset also extends the reboot-mode
>>> framework to add a non-device-based registration function, which
>>> will allow drivers to register using device tree node, while
>>> keeping backward compatibility for existing users of reboot-mode.
>>> This will enable psci driver to register for reboot-mode and
>>> implement a write function, which will save the magic and then
>>> use it in psci reset path to make a vendor-specific reset call
>>> into the firmware. In addition, the patchset will expose a sysfs
>>> entry interface within reboot-mode which can be used by userspace
>>> to view the supported reboot-mode commands.
>>>
>>> The list of vendor-specific reset commands remains open due to
>>> divergent requirements across vendors, but this can be
>>> streamlined and standardized through dedicated device tree
>>> bindings.
>>>
>>> Currently three drivers register with reboot-mode framework -
>>> syscon-reboot-mode, nvmem-reboot-mode and qcom-pon. Consolidated
>>> list of commands currently added across various vendor DTs:
>>>   mode-loader
>>>   mode-normal
>>>   mode-bootloader
>>>   mode-charge
>>>   mode-fastboot
>>>   mode-reboot-ab-update
>>>   mode-recovery
>>>   mode-rescue
>>>   mode-shutdown-thermal
>>>   mode-shutdown-thermal-battery
>>>
>>> Detailed list of commands being used by syscon-reboot-mode:
>>>      arm64/boot/dts/exynos/exynosautov9.dtsi:
>>>     mode-bootloader = <EXYNOSAUTOV9_BOOT_BOOTLOADER>;
>>>     mode-fastboot = <EXYNOSAUTOV9_BOOT_FASTBOOT>;
>>>     mode-recovery = <EXYNOSAUTOV9_BOOT_RECOVERY>;
>>>
>>>      arm64/boot/dts/exynos/google/gs101.dtsi:
>>>          mode-bootloader = <0xfc>;
>>>          mode-charge = <0x0a>;
>>>          mode-fastboot = <0xfa>;
>>>          mode-reboot-ab-update = <0x52>;
>>>          mode-recovery = <0xff>;
>>>          mode-rescue = <0xf9>;
>>>          mode-shutdown-thermal = <0x51>;
>>>          mode-shutdown-thermal-battery = <0x51>;
>>>
>>>      arm64/boot/dts/hisilicon/hi3660-hikey960.dts:
>>>          mode-normal = <0x77665501>;
>>>          mode-bootloader = <0x77665500>;
>>>          mode-recovery = <0x77665502>;
>>>
>>>      arm64/boot/dts/hisilicon/hi6220-hikey.dts:
>>>          mode-normal = <0x77665501>;
>>>          mode-bootloader = <0x77665500>;
>>>          mode-recovery = <0x77665502>;
>>>
>>>      arm64/boot/dts/rockchip/px30.dtsi:
>>>          mode-bootloader = <BOOT_BL_DOWNLOAD>;
>>>          mode-fastboot = <BOOT_FASTBOOT>;
>>>          mode-loader = <BOOT_BL_DOWNLOAD>;
>>>          mode-normal = <BOOT_NORMAL>;
>>>          mode-recovery = <BOOT_RECOVERY>;
>>>
>>>      arm64/boot/dts/rockchip/rk3308.dtsi:
>>>          mode-bootloader = <BOOT_BL_DOWNLOAD>;
>>>          mode-loader = <BOOT_BL_DOWNLOAD>;
>>>          mode-normal = <BOOT_NORMAL>;
>>>          mode-recovery = <BOOT_RECOVERY>;
>>>          mode-fastboot = <BOOT_FASTBOOT>;
>>>
>>>      arm64/boot/dts/rockchip/rk3566-lckfb-tspi.dts:
>>>          mode-normal = <BOOT_NORMAL>;
>>>          mode-loader = <BOOT_BL_DOWNLOAD>;
>>>             mode-recovery = <BOOT_RECOVERY>;
>>>             mode-bootloader = <BOOT_FASTBOOT>;
>>>
>>> Detailed list of commands being used by nvmem-reboot-mode:
>>>      arm64/boot/dts/qcom/pmXXXX.dtsi:(multiple qcom DTs)
>>>             mode-recovery = <0x01>;
>>>             mode-bootloader = <0x02>;
>>>
>>> Previous discussions around SYSTEM_RESET2:
>>> - https://lore.kernel.org/lkml/20230724223057.1208122-2-quic_eberman@quicinc.com/T/
>>> - https://lore.kernel.org/all/4a679542-b48d-7e11-f33a-63535a5c68cb@quicinc.com/
>>>
>>> Signed-off-by: Elliot Berman <quic_eberman at quicinc.com>
>>> Signed-off-by: Shivendra Pratap <shivendra.pratap at oss.qualcomm.com>
>>
>> On ARCH_BRCMSTB:
>>
>> Tested-by: Florian Fainelli <florian.fainelli at broadcom.com>
>>
>> For the sysfs bits, should not we be seeing "psci" instead of "reboot-mode" twice in this path:
>>
>> # cat /sys/class/reboot-mode/reboot-mode/reboot_modes
>> powercycle
> As per current patch, we create a class named - "reboot-mode".
> /sys/class/reboot-mode
> 
> Then comes the DT node name of the registering driver.
> /sys/class/reboot-mode/<DT node name of the registering driver>/

This means that node name becomes part of the ABI? I am not happy about
it. Where is such ABI documented? Because your last patch tells
something completely else!

I strongly insist using compatible as way to find your device, not node
names.

In any case you need to document such ABI in Devicetree bindings,
because sysfs ABI is not enough.

Best regards,
Krzysztof