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

Shivendra Pratap
2025-07-24T14:04:25Z

On 7/24/2025 6:18 PM, Krzysztof Kozlowski wrote:
> 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@quicinc.com>
>>>> Signed-off-by: Shivendra Pratap <shivendra.pratap@oss.qualcomm.com>
>>>
>>> On ARCH_BRCMSTB:
>>>
>>> Tested-by: Florian Fainelli <florian.fainelli@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/ /
>
> 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.
It will look better to switch to compatible. Will define a compatible for
psci reboot-mode binding and align the patch to use the compatible for sysfs.
Current patch defines reboot-mode as a property to psci, hope its fine to
define a compatible for this property like "psci-vendor-reset" or
"psci-reboot-modes"?

>
> In any case you need to document such ABI in Devicetree bindings,
> because sysfs ABI is not enough.
should reboot-mode Devicetree binding document this ABI? Can you
please share some more detail on this?

thanks.
>
> Best regards,
> Krzysztof