.../testing/sysfs-class-reboot-mode-reboot_modes | 38 ++++++ Documentation/devicetree/bindings/arm/psci.yaml | 43 ++++++ arch/arm64/boot/dts/qcom/qcm6490-idp.dts | 7 + arch/arm64/boot/dts/qcom/qcs6490-rb3gen2.dts | 7 + arch/arm64/boot/dts/qcom/sa8775p-ride.dtsi | 7 + arch/arm64/boot/dts/qcom/sa8775p.dtsi | 2 +- arch/arm64/boot/dts/qcom/sc7280.dtsi | 2 +- drivers/firmware/psci/Kconfig | 1 + drivers/firmware/psci/psci.c | 57 +++++++- drivers/power/reset/nvmem-reboot-mode.c | 13 +- drivers/power/reset/qcom-pon.c | 11 +- drivers/power/reset/reboot-mode.c | 148 +++++++++++++++++---- drivers/power/reset/syscon-reboot-mode.c | 11 +- include/linux/reboot-mode.h | 10 +- 14 files changed, 317 insertions(+), 40 deletions(-)
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>
Changes in v12:
- Added lock for list traversals in reboot-mode - by Dmitry.
- Added proper handling for BE and LE cases in reboot-mode - by Dmitry.
- Removed type casting for u64 to u32 conversions. Added limit checks
and used bitwise operations for same - by Andrew.
- Link to v11: https://lore.kernel.org/r/20250717-arm-psci-system_reset2-vendor-reboots-v11-0-df3e2b2183c3@oss.qualcomm.com
Changes in v11:
- Remove reference of cookie in reboot-mode – Arnd/Rob
- Introduce 64-bit magic in reboot-mode to accommodate two 32-bit
arguments – Arnd
- Change reset-type to reboot-mode in psci device tree binding – Arnd
- binding no more mandates two arguments as in v10.
- dt changes done to support this binding.
- Remove obvious comments in psci reset path – Konrad
- Merge sysfs and ABI doc into single patch.
- Fix compilation issue on X86 configs.
- Fix warnings for pr_fmt.
- Link to v10: https://lore.kernel.org/all/569f154d-c714-1714-b898-83a42a38771c@oss.qualcomm.com/
Changes in V10:
- Change in reset-type binding to make cookie as a mandatory
argument.
- Change reboot-mode binding to support additional argument
"cookie".
From Lorenzo:
- Use reboot-mode framework for implementing vendor-resets.
- Modify reboot-mode framework to support two arguments
(magic and cookie).
- Expose sysfs for supported reboot-modes commands.
- List out all existing reboot-mode commands and their users.
- Added this to cover letter.
From Dmitry:
- Modify reboot-mode to support non-device based registration.
- Modify reboot-mode to create a class and device to expose
sysfs interface.
- Link to v9: https://lore.kernel.org/all/20250303-arm-psci-system_reset2-vendor-reboots-v9-0-b2cf4a20feda@oss.qualcomm.com/
Changes in v9:
- Don't fallback to architecturally defined resets from Lorenzo.
- Link to v8: https://lore.kernel.org/r/20241107-arm-psci-system_reset2-vendor-reboots-v8-0-e8715fa65cb5@quicinc.com
Changes in v8:
- Code style nits from Stephen
- Add rb3gen2
- Link to v7: https://lore.kernel.org/r/20241028-arm-psci-system_reset2-vendor-reboots-v7-0-a4c40b0ebc54@quicinc.com
Changes in v7:
- Code style nits from Stephen
- Dropped unnecessary hunk from the sa8775p-ride patch
- Link to v6: https://lore.kernel.org/r/20241018-arm-psci-system_reset2-vendor-reboots-v6-0-50cbe88b0a24@quicinc.com
Changes in v6:
- Rebase to v6.11 and fix trivial conflicts in qcm6490-idp
- Add sa8775p-ride support (same as qcm6490-idp)
- Link to v5: https://lore.kernel.org/r/20240617-arm-psci-system_reset2-vendor-reboots-v5-0-086950f650c8@quicinc.com
Changes in v5:
- Drop the nested "items" in prep for future dtschema tools
- Link to v4: https://lore.kernel.org/r/20240611-arm-psci-system_reset2-vendor-reboots-v4-0-98f55aa74ae8@quicinc.com
Changes in v4:
- Change mode- properties from uint32-matrix to uint32-array
- Restructure the reset-types node so only the restriction is in the
if/then schemas and not the entire definition
- Link to v3: https://lore.kernel.org/r/20240515-arm-psci-system_reset2-vendor-reboots-v3-0-16dd4f9c0ab4@quicinc.com
Changes in v3:
- Limit outer number of items to 1 for mode-* properties
- Move the reboot-mode for psci under a subnode "reset-types"
- Fix the DT node in qcm6490-idp so it doesn't overwrite the one from
sc7820.dtsi
- Link to v2: https://lore.kernel.org/r/20240414-arm-psci-system_reset2-vendor-reboots-v2-0-da9a055a648f@quicinc.com
Changes in v2:
- Fixes to schema as suggested by Rob and Krzysztof
- Add qcm6490 idp as first Qualcomm device to support
- Link to v1: https://lore.kernel.org/r/20231117-arm-psci-system_reset2-vendor-reboots-v1-0-03c4612153e2@quicinc.com
Changes in v1:
- Reference reboot-mode bindings as suggeted by Rob.
- Link to RFC: https://lore.kernel.org/r/20231030-arm-psci-system_reset2-vendor-reboots-v1-0-dcdd63352ad1@quicinc.com
---
Elliot Berman (4):
dt-bindings: arm: Document reboot mode magic
arm64: dts: qcom: qcm6490-idp: Add PSCI SYSTEM_RESET2 types
arm64: dts: qcom: qcs6490-rb3gen2: Add PSCI SYSTEM_RESET2 types
arm64: dts: qcom: sa8775p-ride: Add PSCI SYSTEM_RESET2 types
Shivendra Pratap (4):
power: reset: reboot-mode: Add device tree node-based registration
power: reset: reboot-mode: Add support for 64 bit magic
firmware: psci: Implement vendor-specific resets as reboot-mode
power: reset: reboot-mode: Expose sysfs for registered reboot_modes
.../testing/sysfs-class-reboot-mode-reboot_modes | 38 ++++++
Documentation/devicetree/bindings/arm/psci.yaml | 43 ++++++
arch/arm64/boot/dts/qcom/qcm6490-idp.dts | 7 +
arch/arm64/boot/dts/qcom/qcs6490-rb3gen2.dts | 7 +
arch/arm64/boot/dts/qcom/sa8775p-ride.dtsi | 7 +
arch/arm64/boot/dts/qcom/sa8775p.dtsi | 2 +-
arch/arm64/boot/dts/qcom/sc7280.dtsi | 2 +-
drivers/firmware/psci/Kconfig | 1 +
drivers/firmware/psci/psci.c | 57 +++++++-
drivers/power/reset/nvmem-reboot-mode.c | 13 +-
drivers/power/reset/qcom-pon.c | 11 +-
drivers/power/reset/reboot-mode.c | 148 +++++++++++++++++----
drivers/power/reset/syscon-reboot-mode.c | 11 +-
include/linux/reboot-mode.h | 10 +-
14 files changed, 317 insertions(+), 40 deletions(-)
---
base-commit: 97987520025658f30bb787a99ffbd9bbff9ffc9d
change-id: 20250709-arm-psci-system_reset2-vendor-reboots-46c80044afcf
Best regards,
--
Shivendra Pratap <shivendra.pratap@oss.qualcomm.com>
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 ? -- Florian
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/<DT node name of the registering driver>/ Then the name of the sysfs which is set to "reboot_modes". For case of vendor reset, psci is parent and node name is reboot-mode, so its generalized to: /sys/class/reboot-mode/reboot-mode/reboot_modes -- We can discuss, how to keep it generalized and get some other name in sysfs. suggestions? > > ?
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/<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. In any case you need to document such ABI in Devicetree bindings, because sysfs ABI is not enough. Best regards, Krzysztof
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/<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
On Thu, Jul 24, 2025, at 16:04, Shivendra Pratap wrote:
> On 7/24/2025 6:18 PM, Krzysztof Kozlowski wrote:
>> On 24/07/2025 14:24, Shivendra Pratap wrote:
>> 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"?
>
How about using the reboot driver name as the identifier in sysfs
instead of the compatible string? That would make it independent of
devicetree.
I had a related idea to provide some namespacing on the actual
reboot syscall parameter, as we have two (or more) orthogonal
concepts here, when there is more than one reboot driver and
drivers support multiple modes.
E.g. you could use
syscall(__NR_reboot, LINUX_REBOOT_MAGIC1, LINUX_REBOOT_MAGIC2,
LINUX_REBOOT_CMD_RESTART2, "watchdog");
vs
syscall(__NR_reboot, LINUX_REBOOT_MAGIC1, LINUX_REBOOT_MAGIC2,
LINUX_REBOOT_CMD_RESTART2, "psci");
to pick one of the drivers, or
syscall(__NR_reboot, LINUX_REBOOT_MAGIC1, LINUX_REBOOT_MAGIC2,
LINUX_REBOOT_CMD_RESTART2, "bootloader");
syscall(__NR_reboot, LINUX_REBOOT_MAGIC1, LINUX_REBOOT_MAGIC2,
LINUX_REBOOT_CMD_RESTART2, "recovery");
to ask for a reboot from any driver that supports a mode, or
combine the two and ask a specific mode in a specific driver like
syscall(__NR_reboot, LINUX_REBOOT_MAGIC1, LINUX_REBOOT_MAGIC2,
LINUX_REBOOT_CMD_RESTART2, "psci:bootloader");
Arnd
On 7/24/2025 8:13 PM, Arnd Bergmann wrote: > On Thu, Jul 24, 2025, at 16:04, Shivendra Pratap wrote: >> On 7/24/2025 6:18 PM, Krzysztof Kozlowski wrote: >>> On 24/07/2025 14:24, Shivendra Pratap wrote: > >>> 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"? >> > > How about using the reboot driver name as the identifier in sysfs > instead of the compatible string? That would make it independent of > devicetree. In current patch, psci driver registers to reboot-mode using a device-tree node. So reboot-mode does not has a driver name for psci's reboot registration. its like - reboot_mode_register(reboot, <struct device_node *np>) Now when we want to use the registering reboot driver's name for sysfs, either we- 1, Pass an explicit name from psci driver(say "psci") while registering to reboot-mode. or 2. Create a virtual device in psci driver with name say "psci" and then register for reboot-mode. which one is preferred? suggestions? > > I had a related idea to provide some namespacing on the actual > reboot syscall parameter, as we have two (or more) orthogonal > concepts here, when there is more than one reboot driver and > drivers support multiple modes. > > E.g. you could use > > syscall(__NR_reboot, LINUX_REBOOT_MAGIC1, LINUX_REBOOT_MAGIC2, > LINUX_REBOOT_CMD_RESTART2, "watchdog"); > > vs > > syscall(__NR_reboot, LINUX_REBOOT_MAGIC1, LINUX_REBOOT_MAGIC2, > LINUX_REBOOT_CMD_RESTART2, "psci"); > > to pick one of the drivers, or > > syscall(__NR_reboot, LINUX_REBOOT_MAGIC1, LINUX_REBOOT_MAGIC2, > LINUX_REBOOT_CMD_RESTART2, "bootloader"); > > syscall(__NR_reboot, LINUX_REBOOT_MAGIC1, LINUX_REBOOT_MAGIC2, > LINUX_REBOOT_CMD_RESTART2, "recovery"); > > to ask for a reboot from any driver that supports a mode, or > combine the two and ask a specific mode in a specific driver like > > syscall(__NR_reboot, LINUX_REBOOT_MAGIC1, LINUX_REBOOT_MAGIC2, > LINUX_REBOOT_CMD_RESTART2, "psci:bootloader"); This will introduce an additional feature in the reboot-mode driver. If a colon is present in the command like "<driver name>:bootloader", Call the "<driver name>" specific writes only. We want to add this feature? > > Arnd
On Thu, Jul 24, 2025, at 20:21, Shivendra Pratap wrote:
> On 7/24/2025 8:13 PM, Arnd Bergmann wrote:
>> On Thu, Jul 24, 2025, at 16:04, Shivendra Pratap wrote:
>> How about using the reboot driver name as the identifier in sysfs
>> instead of the compatible string? That would make it independent of
>> devicetree.
> In current patch, psci driver registers to reboot-mode using a device-tree
> node. So reboot-mode does not has a driver name for psci's reboot registration.
> its like - reboot_mode_register(reboot, <struct device_node *np>)
>
> Now when we want to use the registering reboot driver's name for sysfs,
> either we-
> 1, Pass an explicit name from psci driver(say "psci") while registering
> to reboot-mode.
> or
> 2. Create a virtual device in psci driver with name say "psci" and then
> register for reboot-mode.
>
> which one is preferred? suggestions?
I would pick 1, to decouple the namespace from the device and to
keep it simpler.
>> I had a related idea to provide some namespacing on the actual
>> reboot syscall parameter, as we have two (or more) orthogonal
>> concepts here, when there is more than one reboot driver and
>> drivers support multiple modes.
>>
>> E.g. you could use
>>
>> syscall(__NR_reboot, LINUX_REBOOT_MAGIC1, LINUX_REBOOT_MAGIC2,
>> LINUX_REBOOT_CMD_RESTART2, "watchdog");
>>
>> vs
>>
>> syscall(__NR_reboot, LINUX_REBOOT_MAGIC1, LINUX_REBOOT_MAGIC2,
>> LINUX_REBOOT_CMD_RESTART2, "psci");
>>
>> to pick one of the drivers, or
>>
>> syscall(__NR_reboot, LINUX_REBOOT_MAGIC1, LINUX_REBOOT_MAGIC2,
>> LINUX_REBOOT_CMD_RESTART2, "bootloader");
>>
>> syscall(__NR_reboot, LINUX_REBOOT_MAGIC1, LINUX_REBOOT_MAGIC2,
>> LINUX_REBOOT_CMD_RESTART2, "recovery");
>>
>> to ask for a reboot from any driver that supports a mode, or
>> combine the two and ask a specific mode in a specific driver like
>>
>> syscall(__NR_reboot, LINUX_REBOOT_MAGIC1, LINUX_REBOOT_MAGIC2,
>> LINUX_REBOOT_CMD_RESTART2, "psci:bootloader");
> This will introduce an additional feature in the reboot-mode driver.
> If a colon is present in the command like "<driver name>:bootloader",
> Call the "<driver name>" specific writes only.
> We want to add this feature?
I think this will require a little more rework in the reboot
infrastructure, and I did not mean for you to do it now, we
can always decide to do this as a follow-up, but I brought it
up because the way we pick the namespace will limit our options
later.
Arnd
On 7/25/2025 1:44 AM, Arnd Bergmann wrote: > On Thu, Jul 24, 2025, at 20:21, Shivendra Pratap wrote: >> On 7/24/2025 8:13 PM, Arnd Bergmann wrote: >>> On Thu, Jul 24, 2025, at 16:04, Shivendra Pratap wrote: >>> How about using the reboot driver name as the identifier in sysfs >>> instead of the compatible string? That would make it independent of >>> devicetree. >> In current patch, psci driver registers to reboot-mode using a device-tree >> node. So reboot-mode does not has a driver name for psci's reboot registration. >> its like - reboot_mode_register(reboot, <struct device_node *np>) >> >> Now when we want to use the registering reboot driver's name for sysfs, >> either we- >> 1, Pass an explicit name from psci driver(say "psci") while registering >> to reboot-mode. >> or >> 2. Create a virtual device in psci driver with name say "psci" and then >> register for reboot-mode. >> >> which one is preferred? suggestions? > > I would pick 1, to decouple the namespace from the device and to > keep it simpler. Ack. will update the patchset. > >>> I had a related idea to provide some namespacing on the actual >>> reboot syscall parameter, as we have two (or more) orthogonal >>> concepts here, when there is more than one reboot driver and >>> drivers support multiple modes. >>> >>> E.g. you could use >>> >>> syscall(__NR_reboot, LINUX_REBOOT_MAGIC1, LINUX_REBOOT_MAGIC2, >>> LINUX_REBOOT_CMD_RESTART2, "watchdog"); >>> >>> vs >>> >>> syscall(__NR_reboot, LINUX_REBOOT_MAGIC1, LINUX_REBOOT_MAGIC2, >>> LINUX_REBOOT_CMD_RESTART2, "psci"); >>> >>> to pick one of the drivers, or >>> >>> syscall(__NR_reboot, LINUX_REBOOT_MAGIC1, LINUX_REBOOT_MAGIC2, >>> LINUX_REBOOT_CMD_RESTART2, "bootloader"); >>> >>> syscall(__NR_reboot, LINUX_REBOOT_MAGIC1, LINUX_REBOOT_MAGIC2, >>> LINUX_REBOOT_CMD_RESTART2, "recovery"); >>> >>> to ask for a reboot from any driver that supports a mode, or >>> combine the two and ask a specific mode in a specific driver like >>> >>> syscall(__NR_reboot, LINUX_REBOOT_MAGIC1, LINUX_REBOOT_MAGIC2, >>> LINUX_REBOOT_CMD_RESTART2, "psci:bootloader"); >> This will introduce an additional feature in the reboot-mode driver. >> If a colon is present in the command like "<driver name>:bootloader", >> Call the "<driver name>" specific writes only. >> We want to add this feature? > > I think this will require a little more rework in the reboot > infrastructure, and I did not mean for you to do it now, we > can always decide to do this as a follow-up, but I brought it > up because the way we pick the namespace will limit our options > later. sure, thanks. > > Arnd
On 7/24/25 07:43, Arnd Bergmann wrote: > On Thu, Jul 24, 2025, at 16:04, Shivendra Pratap wrote: >> On 7/24/2025 6:18 PM, Krzysztof Kozlowski wrote: >>> On 24/07/2025 14:24, Shivendra Pratap wrote: > >>> 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"? >> > > How about using the reboot driver name as the identifier in sysfs > instead of the compatible string? That would make it independent of > devicetree. +1 > > I had a related idea to provide some namespacing on the actual > reboot syscall parameter, as we have two (or more) orthogonal > concepts here, when there is more than one reboot driver and > drivers support multiple modes. > > E.g. you could use > > syscall(__NR_reboot, LINUX_REBOOT_MAGIC1, LINUX_REBOOT_MAGIC2, > LINUX_REBOOT_CMD_RESTART2, "watchdog"); > > vs > > syscall(__NR_reboot, LINUX_REBOOT_MAGIC1, LINUX_REBOOT_MAGIC2, > LINUX_REBOOT_CMD_RESTART2, "psci"); > > to pick one of the drivers, or > > syscall(__NR_reboot, LINUX_REBOOT_MAGIC1, LINUX_REBOOT_MAGIC2, > LINUX_REBOOT_CMD_RESTART2, "bootloader"); > > syscall(__NR_reboot, LINUX_REBOOT_MAGIC1, LINUX_REBOOT_MAGIC2, > LINUX_REBOOT_CMD_RESTART2, "recovery"); > > to ask for a reboot from any driver that supports a mode, or > combine the two and ask a specific mode in a specific driver like > > syscall(__NR_reboot, LINUX_REBOOT_MAGIC1, LINUX_REBOOT_MAGIC2, > LINUX_REBOOT_CMD_RESTART2, "psci:bootloader"); Yes that seems entirely adequate as well. If there is a single reboot driver registered say "psci" then you could go with the short hand of specifying "bootloader" which would be functionally equivalent to "psci:bootloader". That is, the driver name becomes optional. This would maintain user-space compatibility with existing systems that already support custom reboot modes. -- Florian
On 24/07/2025 16:04, Shivendra Pratap wrote: >>>> 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"? Hm, sorry, what? That's not what I ask, but considering inconsistency mentioned here and in actual ABI document I do not even know what to suggest. > >> >> 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? The binding for the device, whose node name you are using here as ABI, should document the ABI. Best regards, Krzysztof
© 2016 - 2025 Red Hat, Inc.