From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-qt1-f171.google.com (mail-qt1-f171.google.com [209.85.160.171]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id ED45B21D5BE for ; Fri, 18 Jul 2025 21:29:57 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.160.171 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1752874200; cv=none; b=hb/08BrhNER3ajbERoLq1bLhpl84R6U29czurJmd4Dc367qLVdJ3wvlqf+jNihnKHQkGaBx8rHWqqc2MfUi+nkqXN6acFSXIawtIIA4cvi+IpOmfEX/3bokeAexmTgP5tAHnnztWHG8tqcfcgJlQtU4CxTxCa4mffKxVfS6RgyQ= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1752874200; c=relaxed/simple; bh=DKGj5zgW66HcMPoy8Rh9/qrWG7+rLrKazUS66uz0+kw=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=PMT/pKQfbNCRA1bfWA2V5BaxTyPBle+622E/qM4DLaryGrgZcZGAbsP6vcljKd+d7z2heWcn+LwgrqQIKX4ujES4VKC7L7agdZ1zZYTwHiR3ntvqVaUR1mS+Yw2kmIntp/Yhd3h4MFp4pZlhJeQhpo3xHUTnsXhj+Tbkpz9z3to= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=broadcom.com; spf=fail smtp.mailfrom=broadcom.com; dkim=pass (1024-bit key) header.d=broadcom.com header.i=@broadcom.com header.b=PacQjIDs; arc=none smtp.client-ip=209.85.160.171 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=broadcom.com Authentication-Results: smtp.subspace.kernel.org; spf=fail smtp.mailfrom=broadcom.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=broadcom.com header.i=@broadcom.com header.b="PacQjIDs" Received: by mail-qt1-f171.google.com with SMTP id d75a77b69052e-4abc0a296f5so3952401cf.0 for ; Fri, 18 Jul 2025 14:29:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=broadcom.com; s=google; t=1752874197; x=1753478997; darn=vger.kernel.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=X1eGe+D/Z/AW4jpQRHh96jT6N7ULQskAi6plZCwYDAM=; b=PacQjIDsvlQ7sZA36RWy/9LnvIjNT4FLCwqaqL1r3R8PwPX2d+kqMT9L72rbDj5CRy oAjA9K2LwHWMv9ZU3wCx8DcLGQ0yTHclal02sdkB/EE0yoZzrORGuyjBJaNobCerLpSM WF+jCRyjQoY86l1tWUtVJD4LWfhHEAi3qqv/8= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1752874197; x=1753478997; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=X1eGe+D/Z/AW4jpQRHh96jT6N7ULQskAi6plZCwYDAM=; b=Kvc7Bo4HnvTgWxKrSCVyTw3olkL3GcYBH8XmEz2Y9Uysj9iV2jyIRKEYPW1NYzsKUs LwA0yFnyeUCS5elIEApTthQ5K0BisVicBimBxOV5HQpxwbnsKFO2ITiLyxlraReR/8jh vbZ4Nt0u4JWm6sNGvCsG/RaeXr9GJJbmtxPBtChAWCjQ+6vG422JryY8dMkdkAM3kH8/ CbCPKtPXKINc3su39Ta+UGgODjkB2cs50MYIM0ahhzU+8jA0Hpjg56f4rMwH3KoQo0Ct jprPZyeUR96t03Ed+0fTX8SKxImuC19LkFmCHeGzpfmRF9DG4LFaeqJgx6yzoHJIG4AS rOlQ== X-Forwarded-Encrypted: i=1; AJvYcCWL81Nq7OOcUYMhZ57sI+Lfe2X9y+lrgIpg8FNVuZUVSDoHf7BF10ieOxeYAy2FbB6WgnMuI2uk2nlJOIE=@vger.kernel.org X-Gm-Message-State: AOJu0YwnkB655ErpmGkFNskvWqrTCighvVJN0GZj/Dpz2aG9Ya5gOYxR jn0qP7JFz01fE9qQCsQjpqapKlxDMFjHSG1dowtS6DEOnnuNMQWrYdrJkjxxkOVr4Q== X-Gm-Gg: ASbGncvlvTa8Uy53EwxcgGvaL1/sbDtEiSHI5K+hYKMWjGbNA7VDSSI+BYWkWaVALm5 L1vWJohrr/6Sd/J/B9tfxIaGNfWbWiqMlpbyK+cDXV0khAnA3hsTeCIXvzjuvLjIezhoL2dY33e SYd5Kki3r+BSAkCwaU3U9Rktv+D+J9hgJNc25XI/PK3CMb9LMqjMLuW9jBX5FbB328VhHfL97ly pNuR7vg6X7oU0DUSrl7F/sFFwKhQVDMnhP4C2UaY5iK/VFieaRF1FkmEDP97rWfGO1cQd5dlshE olJImWhKqyulEAU/uBXbJAhEvN+RNigMO/za4HApck6oasEVS4MV1OntIHkvwJWjqIupMCvxpH2 cptVtLF38Pi/w+pkZ+JVKQhMFqbRsxGgpOPNgbGiR3vKTO4IwRrFqWqGd2k10Hw== X-Google-Smtp-Source: AGHT+IHfpv+jKiZSsbSAu6fIdHHgAPkuesqv0Jciafy7Wr6ldHI/e3Td9sy9TJjdKnnb7ZgZg6XPvg== X-Received: by 2002:ad4:5d41:0:b0:704:8916:dbc5 with SMTP id 6a1803df08f44-704f6a322femr167113146d6.12.1752874196728; Fri, 18 Jul 2025 14:29:56 -0700 (PDT) Received: from [10.67.48.245] ([192.19.223.252]) by smtp.gmail.com with ESMTPSA id 6a1803df08f44-7051ba6b0fasm11783696d6.65.2025.07.18.14.29.44 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 18 Jul 2025 14:29:55 -0700 (PDT) Message-ID: Date: Fri, 18 Jul 2025 14:29:42 -0700 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v11 0/8] Implement vendor resets for PSCI SYSTEM_RESET2 To: Shivendra Pratap , Bartosz Golaszewski , Bjorn Andersson , Sebastian Reichel , Rob Herring , Sudeep Holla , Souvik Chakravarty , Krzysztof Kozlowski , Conor Dooley , Andy Yan , Mark Rutland , Lorenzo Pieralisi , Arnd Bergmann , Konrad Dybcio , cros-qcom-dts-watchers@chromium.org, Vinod Koul , Catalin Marinas , Will Deacon Cc: Dmitry Baryshkov , Mukesh Ojha , Stephen Boyd , Andre Draszik , linux-pm@vger.kernel.org, linux-kernel@vger.kernel.org, devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-arm-msm@vger.kernel.org, Elliot Berman , Srinivas Kandagatla , Elliot Berman , Konrad Dybcio References: <20250717-arm-psci-system_reset2-vendor-reboots-v11-0-df3e2b2183c3@oss.qualcomm.com> Content-Language: en-US From: Florian Fainelli Autocrypt: addr=florian.fainelli@broadcom.com; keydata= xsBNBFPAG8ABCAC3EO02urEwipgbUNJ1r6oI2Vr/+uE389lSEShN2PmL3MVnzhViSAtrYxeT M0Txqn1tOWoIc4QUl6Ggqf5KP6FoRkCrgMMTnUAINsINYXK+3OLe7HjP10h2jDRX4Ajs4Ghs JrZOBru6rH0YrgAhr6O5gG7NE1jhly+EsOa2MpwOiXO4DE/YKZGuVe6Bh87WqmILs9KvnNrQ PcycQnYKTVpqE95d4M824M5cuRB6D1GrYovCsjA9uxo22kPdOoQRAu5gBBn3AdtALFyQj9DQ KQuc39/i/Kt6XLZ/RsBc6qLs+p+JnEuPJngTSfWvzGjpx0nkwCMi4yBb+xk7Hki4kEslABEB AAHNMEZsb3JpYW4gRmFpbmVsbGkgPGZsb3JpYW4uZmFpbmVsbGlAYnJvYWRjb20uY29tPsLB IQQQAQgAywUCZWl41AUJI+Jo+hcKAAG/SMv+fS3xUQWa0NryPuoRGjsA3SAUAAAAAAAWAAFr ZXktdXNhZ2UtbWFza0BwZ3AuY29tjDAUgAAAAAAgAAdwcmVmZXJyZWQtZW1haWwtZW5jb2Rp bmdAcGdwLmNvbXBncG1pbWUICwkIBwMCAQoFF4AAAAAZGGxkYXA6Ly9rZXlzLmJyb2FkY29t Lm5ldAUbAwAAAAMWAgEFHgEAAAAEFQgJChYhBNXZKpfnkVze1+R8aIExtcQpvGagAAoJEIEx tcQpvGagWPEH/2l0DNr9QkTwJUxOoP9wgHfmVhqc0ZlDsBFv91I3BbhGKI5UATbipKNqG13Z TsBrJHcrnCqnTRS+8n9/myOF0ng2A4YT0EJnayzHugXm+hrkO5O9UEPJ8a+0553VqyoFhHqA zjxj8fUu1px5cbb4R9G4UAySqyeLLeqnYLCKb4+GklGSBGsLMYvLmIDNYlkhMdnnzsSUAS61 WJYW6jjnzMwuKJ0ZHv7xZvSHyhIsFRiYiEs44kiYjbUUMcXor/uLEuTIazGrE3MahuGdjpT2 IOjoMiTsbMc0yfhHp6G/2E769oDXMVxCCbMVpA+LUtVIQEA+8Zr6mX0Yk4nDS7OiBlvOwE0E U8AbwQEIAKxr71oqe+0+MYCc7WafWEcpQHFUwvYLcdBoOnmJPxDwDRpvU5LhqSPvk/yJdh9k 4xUDQu3rm1qIW2I9Puk5n/Jz/lZsqGw8T13DKyu8eMcvaA/irm9lX9El27DPHy/0qsxmxVmU pu9y9S+BmaMb2CM9IuyxMWEl9ruWFS2jAWh/R8CrdnL6+zLk60R7XGzmSJqF09vYNlJ6Bdbs MWDXkYWWP5Ub1ZJGNJQ4qT7g8IN0qXxzLQsmz6tbgLMEHYBGx80bBF8AkdThd6SLhreCN7Uh IR/5NXGqotAZao2xlDpJLuOMQtoH9WVNuuxQQZHVd8if+yp6yRJ5DAmIUt5CCPcAEQEAAcLB gQQYAQIBKwUCU8AbwgUbDAAAAMBdIAQZAQgABgUCU8AbwQAKCRCTYAaomC8PVQ0VCACWk3n+ obFABEp5Rg6Qvspi9kWXcwCcfZV41OIYWhXMoc57ssjCand5noZi8bKg0bxw4qsg+9cNgZ3P N/DFWcNKcAT3Z2/4fTnJqdJS//YcEhlr8uGs+ZWFcqAPbteFCM4dGDRruo69IrHfyyQGx16s CcFlrN8vD066RKevFepb/ml7eYEdN5SRALyEdQMKeCSf3mectdoECEqdF/MWpfWIYQ1hEfdm C2Kztm+h3Nkt9ZQLqc3wsPJZmbD9T0c9Rphfypgw/SfTf2/CHoYVkKqwUIzI59itl5Lze+R5 wDByhWHx2Ud2R7SudmT9XK1e0x7W7a5z11Q6vrzuED5nQvkhAAoJEIExtcQpvGagugcIAJd5 EYe6KM6Y6RvI6TvHp+QgbU5dxvjqSiSvam0Ms3QrLidCtantcGT2Wz/2PlbZqkoJxMQc40rb fXa4xQSvJYj0GWpadrDJUvUu3LEsunDCxdWrmbmwGRKqZraV2oG7YEddmDqOe0Xm/NxeSobc MIlnaE6V0U8f5zNHB7Y46yJjjYT/Ds1TJo3pvwevDWPvv6rdBeV07D9s43frUS6xYd1uFxHC 7dZYWJjZmyUf5evr1W1gCgwLXG0PEi9n3qmz1lelQ8lSocmvxBKtMbX/OKhAfuP/iIwnTsww 95A2SaPiQZA51NywV8OFgsN0ITl2PlZ4Tp9hHERDe6nQCsNI/Us= In-Reply-To: <20250717-arm-psci-system_reset2-vendor-reboots-v11-0-df3e2b2183c3@oss.qualcomm.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 7/17/25 05:46, 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 = ; > mode-fastboot = ; > mode-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 = ; > mode-fastboot = ; > mode-loader = ; > mode-normal = ; > mode-recovery = ; > > arm64/boot/dts/rockchip/rk3308.dtsi: > mode-bootloader = ; > mode-loader = ; > mode-normal = ; > mode-recovery = ; > mode-fastboot = ; > > arm64/boot/dts/rockchip/rk3566-lckfb-tspi.dts: > mode-normal = ; > mode-loader = ; > mode-recovery = ; > mode-bootloader = ; > > 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 > Signed-off-by: Shivendra Pratap I really wished we had stuck with using "/psci/reset-types" because I thought that node name was stable, but regardless, on ARCH_BRCMSTB: Tested-by: Florian Fainelli -- Florian