From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ian Campbell Subject: Re: [PATCH 1/2] xen/arm: Add support of PSCI v1.0 for the host Date: Fri, 9 Oct 2015 16:30:05 +0100 Message-ID: <1444404605.1410.429.camel@citrix.com> References: <1444329901-19055-1-git-send-email-julien.grall@citrix.com> <1444329901-19055-2-git-send-email-julien.grall@citrix.com> <1444403297.1410.417.camel@citrix.com> <20151009151740.GC21629@leverpostej> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZkZcX-00038k-HL for xen-devel@lists.xenproject.org; Fri, 09 Oct 2015 15:30:09 +0000 In-Reply-To: <20151009151740.GC21629@leverpostej> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Mark Rutland Cc: Julien Grall , xen-devel@lists.xenproject.org, Andre Przywara , stefano.stabellini@eu.citrix.com List-Id: xen-devel@lists.xenproject.org On Fri, 2015-10-09 at 16:17 +0100, Mark Rutland wrote: > On Fri, Oct 09, 2015 at 04:08:17PM +0100, Ian Campbell wrote: > > On Thu, 2015-10-08 at 19:45 +0100, Julien Grall wrote: > > > From Xen point of view, PSCI v0.2 and PSCI v1.0 are very similar. All > > > the PSCI calls used within Xen (PSCI_VERSION, CPU_ON, SYSTEM_OFF and > > > SYSTEM_RESET) behaves exactly the same. > > > > > > While there is no compatible string to represent PSCI v1.0 in the DT, > > > it's possible to detect it using the function PSCI_VERSION. > > > > > > The compatible string is now used to detect if the platform may > > > support > > > PSCI v0.2 or higher. > > > > The actual implementation here looks for precisely 0.2 or 1.0, not >= > > 0.2 > > as suggested by this statement. > > > > The PSCI 1.0 spec says (section 5.3.1, intended use of PSCI_VERSION) > > that > > for any 1.y version must be compatible with 1.x when y>x (for those > > functions which existed in 1.x, y might have more). > > > > IOW an OS supporting 1.0 should work with any 1.x. > > This _should_ be the case. Linux assumes future versions are compatible > in this manner. OK, I think we can follow suite then. > There was some minor incompatibility going from 0.2 to 1.0 (the new > state parameter format) that could trip up existing PSCI 0.2 aware OSs, > but hopefully we won't have that kind of thing happen again. Well, the spec has promised not this time around, so I should hope so too ; -) (or it would have to be 2.x) > > > (which begs the question why there is not a "arm,psci-1.x" compat > > string, > > Mark/Andre?) > > There will be one, in fact (see Lorenzo's pull request [1]), but it's > only necessary to allow us to describe PSCI 1.0 implementations which > are not strictly PSCI 0.2 compatible. Otherwise it's harmless to add for > PSCI 1.0 compatible systems, but "arm,psci-0.2" should be sufficient. Are "PSCI 1.0 implementations which are not strictly PSCI 0.2 compatible" valid 1.0 implementations? I think so. In that case it is not correct to say that in addition to all 1.x being compatible 0.2 can also be treated as being in the 1.x "compatibility bucket", without due care. Anyway, I don't think these corner cases affect Xen. Julien, will you add the new compat string in your next version? Ian.