From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mx0b-0031df01.pphosted.com (mx0b-0031df01.pphosted.com [205.220.180.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id F0AB23D5646 for ; Fri, 3 Apr 2026 17:45:44 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=205.220.180.131 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1775238346; cv=none; b=CpWP3XSHj4k9MhoVylSW0RhPmjqZN1WN3qUrnBEH/TBC+oAE7RZuAnSmnDfIpR8JPf9yFMn8CxPx/tWqMCX3c4uRGo2kZBtx7Heg9UQFxDZeIQgl5B19m7oAxiJyFdPulBXRvbJ4w0G+g+SM+wsCXo6jvHSfmEtgmlKkY9CA8U8= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1775238346; c=relaxed/simple; bh=793ilWMo0AtuO5x03/HxCDAGDn8y9fcCAsLObzmOWQo=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=XFUsmNjPvM6WrccTqfQA23fpGtyNSa4wweX07OXG1eQax4WcK/iSUC4INKEjHmi7yDxfmDnL3USx/OgusjvqPkmR6LNPnZMcdKzBgxp+POtKH8DIx9zoc42E5P32YfKk/Yrx4oXFirnckAyob90+JVZ5IvFabiT7bDuXYNmMxV0= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=oss.qualcomm.com; spf=pass smtp.mailfrom=oss.qualcomm.com; dkim=pass (2048-bit key) header.d=qualcomm.com header.i=@qualcomm.com header.b=KFRVUBvZ; dkim=pass (2048-bit key) header.d=oss.qualcomm.com header.i=@oss.qualcomm.com header.b=d/WuHH5l; arc=none smtp.client-ip=205.220.180.131 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=oss.qualcomm.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=oss.qualcomm.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=qualcomm.com header.i=@qualcomm.com header.b="KFRVUBvZ"; dkim=pass (2048-bit key) header.d=oss.qualcomm.com header.i=@oss.qualcomm.com header.b="d/WuHH5l" Received: from pps.filterd (m0279872.ppops.net [127.0.0.1]) by mx0a-0031df01.pphosted.com (8.18.1.11/8.18.1.11) with ESMTP id 633GJJFI2707131 for ; Fri, 3 Apr 2026 17:45:44 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=qualcomm.com; h= cc:content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to; s=qcppdkim1; bh= BcRbm4HgwKmiNI6qxpLJK0dsTMaJBwVAMn+5K7yoUOs=; b=KFRVUBvZOe2C0zgk e8tSDQsHTE3yxdNVLr4Csc4+WzEaw/yFbEGpPxRr+o7SdiPO2uIIxWKQCeYai7f1 8VOMvMRjoCwtBIUerLOoj9EIwHjuwwSTCOM+n8NEBK9k2LpOXYsnYFEq4UVeHXgo zTddW1L4sMsncNekJEOFJRldvhmP9CZ5P+LmbXbOzdhhL3C4+h55g2JlKYGkLV/D GAMkmb1gg+b5j3buQe28PQ4EOlv1T0oEU6s97UklIjxIouG54erk5HZ22DEMRwpt Jrec8/3gieGPqSQDQx6j5q9oY/aGigao8fza4VtqinJco7GEd5+5YKwuRqfdVzE4 EOH/Zw== Received: from mail-pg1-f200.google.com (mail-pg1-f200.google.com [209.85.215.200]) by mx0a-0031df01.pphosted.com (PPS) with ESMTPS id 4d9yfjk9j0-1 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NOT) for ; Fri, 03 Apr 2026 17:45:43 +0000 (GMT) Received: by mail-pg1-f200.google.com with SMTP id 41be03b00d2f7-c7424d91b2dso1138564a12.1 for ; Fri, 03 Apr 2026 10:45:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oss.qualcomm.com; s=google; t=1775238343; x=1775843143; darn=vger.kernel.org; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=BcRbm4HgwKmiNI6qxpLJK0dsTMaJBwVAMn+5K7yoUOs=; b=d/WuHH5lFxa8ac31yVvkE1mnCTTbt+vrZMSrmCXUiQq566hCa3A4uVvz4SPwS5sQHR 7uo2++yErR0dd1xrQk+P+kEF1LWOZSwWaen6qRTFo/5A6KY66qdef+2KUEYnvZiyxfrV 9PFQ0sntFFrEWVWDy+Xpess6qbBMoWdJUrbmbsEMwMGH/vmQZEmKjumthP1OiVMy2Khn 6OmBhtjSwNrCzL+HbPB2kxXoe2ZVRJOvXbqNweWIqduUXD6ifcAsOc1Dn/ALFmdBwKFA wQ3XLfm6BNDlfJVgIAUHeCo+dH3hUJWP8oBx25Kj/Ugwg0IojjP8h80ebxB7Jp0L0XuF JdOA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1775238343; x=1775843143; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :x-gm-gg:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=BcRbm4HgwKmiNI6qxpLJK0dsTMaJBwVAMn+5K7yoUOs=; b=RZkXnFIWSetrcCwKfn6hHrmYn/QFVTWSN2V2xrdsomzUhJOoQZ0oujarOR76FpmNm5 ulXpmROCrixHKys4EqO8U6YxeQzhWsDI21LpVQL5120tna8BUBLpgwnYxiFBJTisvse7 hMLTh9FKZKmSmUTKF17mNDM34rPoPPewIglpD6uv6VEH0XPQ+fF8n0ysBUU6eRRWuMk2 6I2+j5n6CSn3ahwvYybsgBTEoptIYCSgHC1Io0cacW9UobbTSXKGMsJPTO6E8wvYGOMA y14M472ouDbyhASvg0g7ugkgmA3aRnZj25jZY4KLwg8vIe38FbaUmto5Pr5FRg2mF+0x dlDQ== X-Forwarded-Encrypted: i=1; AJvYcCXh/TUv+CdsrBSnRAyeNftuuWvglHKScMubTDY1uR88Gcm6ksvsl0zYuOMuRGxRhAsJUaFny9ucHR+IM5E=@vger.kernel.org X-Gm-Message-State: AOJu0YzGxNBzc9Z1gh9lyKKhGOhR+f57BX6Dnif1pqUl0ASbu+pJO1ZY hQkHlCsJvRk7tkyfsxPvzr6aTeuDSDkHtAoCJgRC3NIevLnp9FLRPMvkl1bIJObMv51t/0ehV3V 8c9vpLN/yTgViLIa5WqZmEbTRLt2BdYwlxTxFSblxfDSrYxjc+lSwfnl0MOfxhOE1hT0= X-Gm-Gg: ATEYQzw5gKOJ//g15WFdpJ71Ob6mI7pA3yufMVfMWGwTQOO+uq6LULAFB6E8rp4nmsD H2P27WEP+DKHW/dQJKiEa64mkydbfueMv7o37o6gXESr6xW14hkeGeNPJ4+HWYvvOZJbOHmSosg PQaoodt7rS2eIWpBg6C7KXUpvCUioAycYFPtSLQP4H/Zf6fCkCb4T0vmCSQw8V3ET2qnIAZ1kDW lBGHQ7G0ajziLsvvqJRy8Hu2eYV4TTB+1CXa40eV7Txxf8/IQ/8PSrWN3g8LKpTuKnBxwwdQ8+t 1B37n4FtL83cZjVTqChtKgdiy7jsS77KLsqp8A7PS9Ru8fiy7Y6gk9LpkiXDxTMRSzUjh5NoZrC 8dcrctwf/v3ZyICwqbcc61jQw56ijLL2jx4kVv6L4DipuvNFRG597o8+t X-Received: by 2002:a05:6a21:9995:b0:39c:4ca1:345b with SMTP id adf61e73a8af0-39f2efadfc1mr3753210637.38.1775238342843; Fri, 03 Apr 2026 10:45:42 -0700 (PDT) X-Received: by 2002:a05:6a21:9995:b0:39c:4ca1:345b with SMTP id adf61e73a8af0-39f2efadfc1mr3753157637.38.1775238342245; Fri, 03 Apr 2026 10:45:42 -0700 (PDT) Received: from [192.168.29.31] ([49.43.227.38]) by smtp.gmail.com with ESMTPSA id 41be03b00d2f7-c76c6563597sm6988128a12.16.2026.04.03.10.45.34 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 03 Apr 2026 10:45:41 -0700 (PDT) Message-ID: <547c006b-231c-430c-a69e-f80334c4f81f@oss.qualcomm.com> Date: Fri, 3 Apr 2026 23:15:32 +0530 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 v20 06/10] power: reset: Add psci-reboot-mode driver To: Lorenzo Pieralisi Cc: Arnd Bergmann , Bjorn Andersson , Sebastian Reichel , Rob Herring , Souvik Chakravarty , Krzysztof Kozlowski , Andy Yan , Matthias Brugger , Mark Rutland , Conor Dooley , Konrad Dybcio , John Stultz , Moritz Fischer , Bartosz Golaszewski , Sudeep Holla , Florian Fainelli , Krzysztof Kozlowski , Dmitry Baryshkov , Mukesh Ojha , Andre Draszik , Kathiravan Thirumoorthy , linux-pm@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-arm-msm@vger.kernel.org, devicetree@vger.kernel.org, Srinivas Kandagatla References: <20260304-arm-psci-system_reset2-vendor-reboots-v20-0-cf7d346b8372@oss.qualcomm.com> <20260304-arm-psci-system_reset2-vendor-reboots-v20-6-cf7d346b8372@oss.qualcomm.com> <93a78bc2-4fd1-41bd-bf4a-b433b06fc218@oss.qualcomm.com> Content-Language: en-US From: Shivendra Pratap In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Proofpoint-GUID: GCQVRJ7jXefeB7ifkNmI4du5ynedc2ra X-Proofpoint-Spam-Details-Enc: AW1haW4tMjYwNDAzMDE1OCBTYWx0ZWRfX98uee1V0HLCU Vm5l4pxI15t3X/4jEvrWnJ6XJDX/9d6GrDv86BKa8ik2IaoP7I+apG1+fHmNadolUARMp38Rjy6 drr9q0pU7S/51vyw24l58+85s2BzIbW2hfrSrSQMdxP3TeqYq0C5NUqmJo9/MPokmEvV0/LZ3kZ dmQ5gURcYLfB0b8IxuwOnC9qGLzSPFX1046jgvZhpzoZKVvwSFyj3SB1Z4HzRF3KVmpmk0Tu5L+ WYZfbSA6U54SB32uAxKAfYG0fKaRRPs+LBBkzr6r5nVyjQDt43nnQ84sipEEnZPyR0MOBmpwhiT Qa8qM2zpOHN4kzecQ5vZI5zFmt5EQiTfbrjpiP55RRmq7ea0+2rpF6oT0VGOjMnMKk0S1jzfHyD FEkQcsUP/RxvY4Q4r0MsECS8u+BvrAYlBNXJdDaCNpXdmFbaQoGmHXb3BhN29cD2FJBMJjKR1D5 z/giyUeK/F+iBPzRzWg== X-Authority-Analysis: v=2.4 cv=OrpCCi/t c=1 sm=1 tr=0 ts=69cffcc7 cx=c_pps a=oF/VQ+ItUULfLr/lQ2/icg==:117 a=2dos1RgzJhmu1+008kacPQ==:17 a=IkcTkHD0fZMA:10 a=A5OVakUREuEA:10 a=s4-Qcg_JpJYA:10 a=VkNPw1HP01LnGYTKEx00:22 a=u7WPNUs3qKkmUXheDGA7:22 a=yx91gb_oNiZeI1HMLzn7:22 a=F0Qtw4M1lXcpx3oWCRwA:9 a=QEXdDO2ut3YA:10 a=3WC7DwWrALyhR5TkjVHa:22 X-Proofpoint-ORIG-GUID: GCQVRJ7jXefeB7ifkNmI4du5ynedc2ra X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.293,Aquarius:18.0.1143,Hydra:6.1.51,FMLib:17.12.100.49 definitions=2026-04-03_05,2026-04-03_01,2025-10-01_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 impostorscore=0 malwarescore=0 adultscore=0 suspectscore=0 phishscore=0 lowpriorityscore=0 spamscore=0 bulkscore=0 clxscore=1015 priorityscore=1501 classifier=typeunknown authscore=0 authtc= authcc= route=outbound adjust=0 reason=mlx scancount=1 engine=8.22.0-2603050001 definitions=main-2604030158 On 03-04-2026 21:20, Lorenzo Pieralisi wrote: > On Fri, Apr 03, 2026 at 12:05:27AM +0530, Shivendra Pratap wrote: >> >> >> On 01-04-2026 20:07, Lorenzo Pieralisi wrote: >>> On Tue, Mar 31, 2026 at 11:30:09PM +0530, Shivendra Pratap wrote: >>>> >>>> >>>> On 27-03-2026 19:25, Lorenzo Pieralisi wrote: >>>>> On Wed, Mar 04, 2026 at 11:33:06PM +0530, Shivendra Pratap wrote: >>>>>> PSCI supports different types of resets like COLD reset, ARCH WARM >> >> [snip..] >> >>>>>> + * Predefined reboot-modes are defined as per the values >>>>>> + * of enum reboot_mode defined in the kernel: reboot.c. >>>>>> + */ >>>>>> +static struct mode_info psci_resets[] = { >>>>>> + { .mode = "warm", .magic = REBOOT_WARM}, >>>>>> + { .mode = "soft", .magic = REBOOT_SOFT}, >>>>>> + { .mode = "cold", .magic = REBOOT_COLD}, >>> >>> These strings match the command userspace issue right ? I think that we >>> should make them match the corresponding PSCI reset types, the list above >>> maps command to reboot_mode values and those can belong to any reboot >>> mode driver to be honest they don't make much sense in a PSCI reboot >>> mode driver only. >>> >>> It is a question for everyone here: would it make sense to make these >>> predefined resets a set of strings, eg: >>> >>> psci-system-reset >>> psci-system-reset2-arch-warm-reset >>> >>> and then vendor resets: >>> >>> psci-system-reset2-vendor-reset >> >> Can you share bit more details on this? We are already defining the string >> from userspace in the struct - eg: ".mode = "warm". > > "warm","soft","cold" are not strictly speaking PSCI concepts and mean nothing > well defined to user space and even if they did, they would not belong in > the PSCI reboot mode driver but in generic code. > > Spelling out what a reset is might help instead, again, this is just my > opinion, I don't know how the semantics of resets have been handled thus > far. > > If userspace issues a LINUX_REBOOT_CMD_RESTART2 with arg, say, > "psci-system-reset2-arch-warm-reset" it is pretty clear what it wants > to do in PSCI. ok. got it. so it predef-modes. reboot psci-system-reset2-arch-warm-reset =>goes for => ARCH WARM RESET. etc.. > > Again, it is a suggestion, comments welcome. > >> yes we can move away from enum reboot_mode and use custom psci defines one - >> Ack. >> >>> >> >> [snip ..] >> >>>>>> + >>>>>> +/* >>>>>> + * arg1 is reset_type(Low 32 bit of magic). >>>>>> + * arg2 is cookie(High 32 bit of magic). >>>>>> + * If reset_type is 0, cookie will be used to decide the reset command. >>>>>> + */ >>>>>> +static int psci_reboot_mode_write(struct reboot_mode_driver *reboot, u64 magic) >>>>>> +{ >>>>>> + u32 reset_type = REBOOT_MODE_ARG1(magic); >>>>>> + u32 cookie = REBOOT_MODE_ARG2(magic); >>>>>> + >>>>>> + if (reset_type == 0) { >>>>>> + if (cookie == REBOOT_WARM || cookie == REBOOT_SOFT) >>>>>> + psci_set_reset_cmd(true, 0, 0); >>>>>> + else >>>>>> + psci_set_reset_cmd(false, 0, 0); >>>>>> + } else { >>>>>> + psci_set_reset_cmd(true, reset_type, cookie); >>>>>> + } >>>>> >>>>> I don't think that psci_set_reset_cmd() has the right interface (and this >>>>> nested if is too complicated for my taste). All we need to pass is reset-type >>>>> and cookie (and if the reset is one of the predefined ones, reset-type is 0 >>>>> and cookie is the REBOOT_* cookie). >>>>> >>>>> Then the PSCI firmware driver will take the action according to what >>>>> resets are available. >>>>> >>>>> How does it sound ? >>>> >>>> So we mean these checks will move to the psci driver? Sorry for re-iterating >>>> the question. >>> >>> Given what I say above, I believe that something we can do is mapping the magic >>> to an enum like: >>> >>> PSCI_SYSTEM_RESET >>> PSCI_SYSTEM_RESET2_ARCH_SYSTEM_WARM_RESET >>> PSCI_SYSTEM_RESET2_VENDOR_RESET >>> >>> and can add a probe function into PSCI driver similar to psci_has_osi_support() but >>> to probe for SYSTEM_RESET2 and initialize the predefined strings accordingly, >>> depending on its presence. >> >> Not able to get it cleanly. >> >> 1. Will move away from reboot_mode enum for pre-defined modes and define new >> enum defining these modes- fine. >> 2. get SYSTEM_RESET2 is supported from psci exported function -- fine, but >> how we use it here now, as we do not want to send the reset_cmd from >> psci_set_reset_cmd now? > > You do keep psci_set_reset_cmd() but all it is used for is setting a struct > shared with the PSCI driver where you initialize the enum above, possibly > with a cookie if it is a vendor reset. > >> 3. For pre-defined modes, warm/soft or cold - reset_type and cookie, both >> are zero, sys_reset2 or sys_reset2 decides the ARCH reset vs cold reset. >> 4. For vendor-rest , we use sys_reset2 with reset_type and cookie. > > Yes. Ack. >> All above is done in reboot_notifier call at psci-reboot-mode. >> -- >> >> Now in the final restart_notifier->psci_sys_reset -- >> >> If panic is in progress, we do not use any of the cmd based reset params and >> go with the legacy reset. So we need to preserve the values that were set >> from psci-reboot-mode. >> >> Did not understand the proposed suggestion in above usecase. Need more input >> on this. > > I explained above. The reboot mode driver sets the command to carry out > depending on the string coming from user space and whether PSCI supports > SYSTEM_RESET2 or not. got it. working on it. thanks. >> -- >> >> One other option is to have a restart_notifier in psci-reboot-mode, with >> lesser priority than psci_sys_rest and then handle all the case including >> panic and sys_reset2. > > No. Ack. thanks, Shivendra