On 7/11/2025 1:50 AM, Florian Fainelli wrote: > On 7/10/25 02:15, 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. As the >> vendor-specific reset needs two arguments reset_type and cookie >> to be passes to the firmware, enhance the reboot-mode framework >> to support two arguments (magic and cookie), for each reboot-mode >> command, where cookie will be optional. >> >> 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 DT 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_with_cookie function which will save the >> magic(reset_type) and cookie 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> > > Humm, something changed compared to the last version that I tested from Elliot which worked ok. With this patch applied and the following Device Tree snippet: > > psci { > method = "smc"; > compatible = "arm,psci-0.2", "arm,psci"; > cpu_on = <0xc4000003>; > cpu_suspend = <0xc4000001>; > cpu_off = <0x84000002>; > > reset-types { > mode-powercycle = <0x01>; Yes, Now passing the cookie value is mandatory, when defining your "reset-types". So your device tree entry should be: mode-powercycle = <0x01 0>; Please try by passing changing the dt entry as above. The dt-binding document is updated and does talks about the mandatory cookie to be passed in reset-type. > }; > }; > > I get the following invoking "reboot powercycle": > > # reboot powercycle > [ 21.403188] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000 is not a phandle reference > [ 21.412032] Mem abort info:extended_property): /rdb/waketimer@841a840:interrupts-extended: cell 0 is not a phandle reference > [ 21.414840] ESR = 0x0000000086000004operty): /rdb/waketimer@841a840:interrupts-extended: cell 2 is not a phandle reference > [ 21.418601] EC = 0x21: IABT (current EL), IL = 32 bitsparent: cell 0 is not a phandle reference > [ 21.423927] SET = 0, FnV = 0: /rdb/xhci_v2@8d00000:phys: cell 0 is not a phandle reference > [ 21.426988] EA = 0, S1PTW = 0 /rdb/sata@8b0a000/sata-port@0:phys: cell 0 is not a phandle reference > [ 21.430138] FSC = 0x04: level 0 translation fault:phys: cell 0 is not a phandle reference > [ 21.435054] user pgtable: 4k pages, 48-bit VAs, pgdp=000000010112c000 a phandle reference > [ 21.441508] [0000000000000000] pgd=0000000000000000, p4d=0000000000000000handle reference > [ 21.448318] Internal error: Oops: 0000000086000004 [#1] SMPcell 0 is not a phandle reference > [ 21.453990] Modules linked in: bdc udc_core/thermal-zones/cpu-thermal:thermal-sensors: cell 0 is not a phandle reference > [ 21.458188] CPU: 0 UID: 0 PID: 1566 Comm: reboot Not tainted 6.16.0-rc5-next-20250710-gdd78270edd5a #2 NONE 4) > [ 21.468032] Hardware name: BCX972160DV (DT)ases property name must include only lowercase and '-' > [ 21.472221] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)only lowercase and '-' > [ 21.479193] pc : 0x0s_paths): /aliases:pcie0: aliases property is not a valid node (/pcie@8b10000) > [ 21.481388] lr : reboot_mode_notify+0x64/0x80es property name must include only lowercase and '-' > [ 21.485760] sp : ffff80008344bbe0iases: aliases property name must include only lowercase and '-' > [ 21.489079] x29: ffff80008344bbe0 x28: ffff0000c3bb3d00 x27: ffff800080ab58e8ly lowercase and '-' > [ 21.496228] x26: 0000000000000000 x25: ffff0000c3bb3d00 x24: ffff800082cf9bc8ly lowercase and '-' > [ 21.503376] x23: ffff80008344bcb8 x22: 0000000000000001 x21: ffff0000c31b87b0 > [ 21.510524] x20: 00000000fffffffc x19: ffff0000c31b8780 x18: 0000000000000000 > [ 21.517673] x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000 > [ 21.524821] x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000 > [ 21.531969] x11: 0000000000000000 x10: 00007fffc02bb958 x9 : 0000000000000010 > [ 21.539118] x8 : 0101010101010101 x7 : 0000000000000000 x6 : 000080c38080ffff > [ 21.546266] x5 : ffff0000c3000000 x4 : 0000808000800000 x3 : 0000000000000000 > [ 21.553415] x2 : 0000000000000000 x1 : 0000000000000001 x0 : ffff0000c31b8780 > [ 21.560565] Call trace: > [ 21.563014] 0x0 (P) > [ 21.565205] notifier_call_chain+0x70/0x120 > [ 21.569401] blocking_notifier_call_chain+0x4c/0x78 > [ 21.574288] kernel_restart+0x30/0xc8 > [ 21.577957] __do_sys_reboot+0x1c8/0x268 > [ 21.581886] __arm64_sys_reboot+0x28/0x38 > [ 21.585902] invoke_syscall+0x4c/0x118 > [ 21.589660] el0_svc_common.constprop.0+0x44/0xe8 > [ 21.594373] do_el0_svc+0x20/0x30 > [ 21.597694] el0_svc+0x18/0x58 > [ 21.600758] el0t_64_sync_handler+0x98/0xe0 > [ 21.604947] el0t_64_sync+0x154/0x158 > [ 21.608625] Code: ???????? ???????? ???????? ???????? (????????) > [ 21.614730] ---[ end trace 0000000000000000 ]--- > Segmentation fault > # > > -- > Florian
