[PATCH v12 0/8] Implement vendor resets for PSCI SYSTEM_RESET2
Shivendra Pratap
shivendra.pratap at oss.qualcomm.com
Thu Jul 24 07:04:13 PDT 2025
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 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.
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
More information about the linux-arm-kernel
mailing list