| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <a4d937482f2a94fbb822150fbc6c06c914940e1a.camel@linaro.org>
Date: Wed, 30 Jul 2025 09:50:11 +0100
From: André Draszik <andre.draszik@...aro.org>
To: Shivendra Pratap <shivendra.pratap@....qualcomm.com>, Bartosz
Golaszewski <bartosz.golaszewski@...aro.org>, Bjorn Andersson
<andersson@...nel.org>, Sebastian Reichel <sre@...nel.org>, Rob Herring
<robh@...nel.org>, Sudeep Holla <sudeep.holla@....com>, Souvik Chakravarty
<Souvik.Chakravarty@....com>, Krzysztof Kozlowski <krzk+dt@...nel.org>,
Conor Dooley <conor+dt@...nel.org>, Andy Yan <andy.yan@...k-chips.com>,
Mark Rutland <mark.rutland@....com>, Lorenzo Pieralisi
<lpieralisi@...nel.org>, Arnd Bergmann <arnd@...db.de>, Konrad Dybcio
<konradybcio@...nel.org>, cros-qcom-dts-watchers@...omium.org, Vinod Koul
<vkoul@...nel.org>, Catalin Marinas <catalin.marinas@....com>, Will Deacon
<will@...nel.org>, Florian Fainelli <florian.fainelli@...adcom.com>
Cc: Dmitry Baryshkov <dmitry.baryshkov@....qualcomm.com>, Mukesh Ojha
<mukesh.ojha@....qualcomm.com>, Stephen Boyd <swboyd@...omium.org>,
linux-pm@...r.kernel.org, linux-kernel@...r.kernel.org,
devicetree@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
linux-arm-msm@...r.kernel.org, Elliot Berman <quic_eberman@...cinc.com>,
Srinivas Kandagatla
<srini@...nel.org>, Elliot Berman <elliot.berman@....qualcomm.com>, Konrad
Dybcio <konrad.dybcio@....qualcomm.com>
Subject: Re: [PATCH v13 00/10] Implement vendor resets for PSCI SYSTEM_RESET2
On Sun, 2025-07-27 at 21:54 +0530, 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>;
Just for completeness, on gs101 we also pass kernel-generated
modes from kernel_restart() or panic(), specifically DM verity's
'dm-verity device corrupted':
mode-dm-verity-device-corrupted = <0x50>;
Cheers,
Andre'
>
> 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@...cinc.com>
> Signed-off-by: Shivendra Pratap <shivendra.pratap@....qualcomm.com>
>
> Changes in v13:
> - Split patch1 into two (Synchronize list traversal and DT node-based
> registration) - by Dmitry.
> - Move mutex lock inside get_reboot_mode_magic - by Dmitry.
> - Reorder the patches – pull patch8 for exposing reboot-mode sysfs before
> psci patch - to align the change in reboot-mode sysfs patch.
> - Update patch- reboot-mode: Expose sysfs for registered reboot_modes
> - Introduce a driver_name in reboot_mode_register. This will be used
> in sysfs creation - by Arnd.
> - Update documentation and commit text for above.
> - Fix release function to properly call delete attr file.
> - Fix sparse warning for devres_find.
> - Add error handling for devres_find.
> - Split ABI documentation as a separate patch and update ABI documentation
> for usage of driver-name in sysfs - by Arnd
> - Update patch - psci: Implement vendor-specific resets as reboot-mode
> - Fix Kconfig for CONFIG related warning.
> - Add driver_name as "psci" in register call to reboot-mode - by Arnd
> - Link to v12: https://lore.kernel.org/r/20250721-arm-psci-system_reset2-vendor-reboots-v12-0-87bac3ec422e@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 (6):
> power: reset: reboot-mode: Synchronize list traversal
> power: reset: reboot-mode: Add device tree node-based registration
> power: reset: reboot-mode: Add support for 64 bit magic
> Documentation: ABI: Add sysfs-class-reboot-mode-reboot_modes
> power: reset: reboot-mode: Expose sysfs for registered reboot_modes
> firmware: psci: Implement vendor-specific resets as reboot-mode
>
> .../testing/sysfs-class-reboot-mode-reboot_modes | 39 +++++
> 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 | 2 +
> 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 | 174 +++++++++++++++++----
> drivers/power/reset/syscon-reboot-mode.c | 11 +-
> include/linux/reboot-mode.h | 11 +-
> 14 files changed, 342 insertions(+), 44 deletions(-)
> ---
> base-commit: d7af19298454ed155f5cf67201a70f5cf836c842
> change-id: 20250709-arm-psci-system_reset2-vendor-reboots-46c80044afcf
>
> Best regards,
Powered by blists - more mailing lists