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@xxxxxxxxxxx/T/ >>>> - https://lore.kernel.org/all/4a679542-b48d-7e11-f33a-63535a5c68cb@xxxxxxxxxxx/ >>>> >>>> Signed-off-by: Elliot Berman <quic_eberman@xxxxxxxxxxx> >>>> Signed-off-by: Shivendra Pratap <shivendra.pratap@xxxxxxxxxxxxxxxx> >>> >>> On ARCH_BRCMSTB: >>> >>> Tested-by: Florian Fainelli <florian.fainelli@xxxxxxxxxxxx> >>> >>> 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
