Re: [PATCH v14 00/10] Implement vendor resets for PSCI SYSTEM_RESET2

[Kathiravan Thirumoorthy <kathiravan.thirumoorthy@oss.qualcomm.com>]

On 9/2/2025 6:40 PM, Shivendra Pratap wrote:
>
> On 8/28/2025 1:35 PM, Kathiravan Thirumoorthy wrote:
>> On 8/15/2025 8:05 PM, 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
>>>
>>> On gs101 we also pass kernel-generated modes from kernel_restart()
>>> or panic(), specifically DM verity's 'dm-verity device corrupted':
>>>      mode-dm-verity-device-corrupted = <0x50>;
>>>
>>> - thanks Andre' for providing this.
>>>
>>> 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@quicinc.com>
>>> Signed-off-by: Shivendra Pratap<shivendra.pratap@oss.qualcomm.com>
>>
>> With this series, 'edl' mode is working fine in QCOM's IPQ5424 SoC. So
>>
>> Tested-by: Kathiravan Thirumoorthy <kathiravan.thirumoorthy@oss.qualcomm.com> # IPQ5424-RDP466
>>
> Thanks for giving time for testing this series for IPQ5424. So we have PSCI SYS reset2 support for
> IPQ5424 firmware?


Yeah, the latest IPQ5424 firmware (To be specific - 
TZ.WIN_WC.1.0-00043-IPQ5424MAPAANAZT-1 onwards) supports PSCI SYS RESET2.


> and did we make any extra changes in DT for edl mode?


Yes, I submitted the DTS patch[1] for this similar to the other platforms.

[1] [PATCH] arm64: dts: qcom: ipq5424: Add support for emergency 
download mode - Kathiravan Thirumoorthy 
<https://lore.kernel.org/linux-arm-msm/20250828-ipq5424-edl-v1-1-d6a403800023@oss.qualcomm.com/>.


>
> thanks,
> Shivendra