Received: by 2002:a25:1506:0:0:0:0:0 with SMTP id 6csp4849638ybv; Wed, 26 Feb 2020 04:10:07 -0800 (PST) X-Google-Smtp-Source: APXvYqwqklruRo9USQSIUk76SGWpdZxJqkqdzupVhY/nVJq/PgWr8SRO2H/j8SBuUqMucOMlsN0+ X-Received: by 2002:aca:e146:: with SMTP id y67mr2646720oig.93.1582719007563; Wed, 26 Feb 2020 04:10:07 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1582719007; cv=none; d=google.com; s=arc-20160816; b=I7XRtF1loDGBEiZk57TiZCt0ugH0I4wst40ZjGHuh8C2/sUSXqdrTVT1hZLdrLkNc7 5yI5uNQe4a0G2w/Pf+kuYbcjSfMfaYzfYZplrYOuM4VYN8CYI8dbfzTF1j/SXuAv0GS7 cUTE2RUHoePZR/xL9pshliavS/dQnnFf+wHAt2a6+sMhKK4yIpmHomuo/CMhWISjaHV1 ulnDav5UhpSziEioghjxfDxT7avBPXJzgW45ZNU4v99S6WGTFX4FD8v0y/Axo65LARUu PKtk8Bb+KTentF0EsO5V4eLQa/M6Q0i0FVYg4tdiNN7s62T/6PCyO6yz37DdylRo+6b7 O2Qg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=jfQYxmURyRU30NmZWNTMOcSupfRqyr/UgkpjCc+xYzA=; b=oqOHtOLcUvGZK+DgMuyRwqbgDqHFHq5dagQNRAACt1uS1RMVk++RQ5AHMCZuc0YXxC G3ZvMTJf8XMfHBUtBBvhtzldPZ6VQakiEqHaUByEUSPbsGbK1fAX8XfwY2KU0N4Aqkeg gPgP1f3dk8T8Yp5zBhXI90+rtBxeYT3MV0JnSQPhKNFLAWP6zREhthHShxWVyheVNTfN +UOYKbuztAzyKvee2yvkD2fFfaMo29x2bqTaYTwcUqMNUJgIWIEmEEDZM8d2YObuovh0 lQdgX5ulBUH5WlUSChbhwwjW9MOrCxXpYjK8afkTbokuiFbBQ8xn4ivWH5h1WGJ38iAJ VFiw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id v21si1087805otp.189.2020.02.26.04.09.53; Wed, 26 Feb 2020 04:10:07 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726822AbgBZMJ2 (ORCPT + 99 others); Wed, 26 Feb 2020 07:09:28 -0500 Received: from foss.arm.com ([217.140.110.172]:34998 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726272AbgBZMJ2 (ORCPT ); Wed, 26 Feb 2020 07:09:28 -0500 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 352171FB; Wed, 26 Feb 2020 04:09:25 -0800 (PST) Received: from lakrids.cambridge.arm.com (usa-sjc-imap-foss1.foss.arm.com [10.121.207.14]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id D98253FA00; Wed, 26 Feb 2020 04:09:23 -0800 (PST) Date: Wed, 26 Feb 2020 12:09:19 +0000 From: Mark Rutland To: Elliot Berman Cc: Lorenzo Pieralisi , Sudeep Holla , Bjorn Andersson , Trilok Soni , Prasad Sodagudi , David Collins , linux-arm-kernel@lists.infradead.org, linux-arm-msm@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v2 1/3] dt: psci: Add arm,psci-sys-reset2-type property Message-ID: <20200226120918.GA21897@lakrids.cambridge.arm.com> References: <1582577858-12410-1-git-send-email-eberman@codeaurora.org> <1582577858-12410-2-git-send-email-eberman@codeaurora.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1582577858-12410-2-git-send-email-eberman@codeaurora.org> User-Agent: Mutt/1.11.1+11 (2f07cb52) (2018-12-01) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Feb 24, 2020 at 12:57:36PM -0800, Elliot Berman wrote: > Some implementors of PSCI may relax the requirements of the PSCI > architectural warm reset. In order to comply with PSCI specification, a > different reset_type value must be used. This reads as-if you're saying the firmware isn't spec compliant, and this is a workaround in order to get the expected behaviour. Can you please elaborate on what you mean by "relax the requirements" here? What's your firmware doing or not doing that you want to avoid? > The alternate PSCI SYSTEM_RESET2 may be used in all warm/soft reboot > scenarios, replacing the architectural warm reset. I assume you mean SYSTEM_REET2's SYSTEM_WARM_RESET reset? Please call that out explicitly by name -- it makes this easier to look up, and if/when more architectural resets are added the commit message won't become ambiguous. > > Signed-off-by: Elliot Berman > --- > Documentation/devicetree/bindings/arm/psci.yaml | 5 +++++ > 1 file changed, 5 insertions(+) > > diff --git a/Documentation/devicetree/bindings/arm/psci.yaml b/Documentation/devicetree/bindings/arm/psci.yaml > index 8ef8542..469256a2 100644 > --- a/Documentation/devicetree/bindings/arm/psci.yaml > +++ b/Documentation/devicetree/bindings/arm/psci.yaml > @@ -102,6 +102,11 @@ properties: > [1] Kernel documentation - ARM idle states bindings > Documentation/devicetree/bindings/arm/idle-states.txt > > + arm,psci-sys-reset2-param: > + $ref: /schemas/types.yaml#/definitions/uint32 > + description: | > + reset_param value to use during a warm or soft reboot. A "soft" reboot isn't a PSCI concept, so I'm worried this is just hooking up magic values for Linux internals. I'd like to better understand what you're trying to achieve here. Thanks, Mark. > + > "#power-domain-cells": > description: > The number of cells in a PM domain specifier as per binding in [3]. > -- > The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, > a Linux Foundation Collaborative Project