On Wed, Jul 31, 2013 at 12:49:20PM -0500, Rob Herring wrote:

On 07/31/2013 12:24 PM, Matt Sealey wrote:

quoted

On Wed, Jul 31, 2013 at 8:49 AM, Mark Rutland [off-list ref] wrote:

[snip]

quoted

quoted

quoted

* An AArch64 guest under an AArch64 hypervisor/sm would use the 64-bit
convention or the 32-bit convention depending on how the sm is
written, but it doesn't matter which is used if both can be
supported.. but you'd only want to use one of them.

Not all implementation will implement both, so there needs to be a way
to describe that. Which is actually used is up to the OS.

Okay but putting both ways in a single node, and describing two
function ids (per property or with two properties) is what I was
getting at.. for the one case where you can use both at once, the
device tree description is king here.

I am a little concerned that the support for this is going down the
route of telling the OS all possible ways to do the same thing instead
of trying to get into using a single, preferred way in the common
cases.

Putting both call methods in the same node, doubling the function id
property lengths, or suffixing function id properties to do it seems
like putting information in the tree purely for the sake of it. In
what cases would it (uncommon cases only being existing, pre-PCSI
pre-SMC-conventions potentially for other things). In the case of PSCI
there's an opportunity to be strict about it.. why would it be sane to
allow a mixed implementation? Dictate that either support all the
64-bit versions or all the 32-bit versions or both? And if both are
supported, dictate in the device tree which the OS should be using.

The DT is about description, not policy.  If multiple usable flavours of
the PSCI interface exist, then they exist, and there's no special reason
to hide one of them from the DT that I can see.

I take the point that we shouldn't describe useless or redundant
information for no good reason, though.

quoted

What about having two nodes? There is nothing in device trees that
says you can't have two psci { compatible="arm,psci-0.2" } nodes, one
with method=smc and one with method=smc64 or hvc64 or what have you.
Parsing and setup of the PSCI code can be quit early if it's not the
"desirable" method for the OS (i.e. 64-bit on a 32-bit kernel). Then
each node follows the exact same definition, and the differentiator is
the call method and not the property names or complicating their
contents.

+1

This would certainly be easier for things like a hypervisor to parse and
update.

Can you elaborate on that?

Wouldn't a hypervisor always rip out and replace PSCI node(s) with
its own?  Allowing the firmware's PSCI interface to "show through" to a
guest VM sounds unwise.

I'm not sure why having multiple nodes makes this easier.

Having two nodes just moves information around.  Does it really simplify
anything?


With the multiple nodes approach, you might actually need 3 nodes if
you are providing backwards compatible support for psci-0.1 callers: one
for psci-0.2 32-bit, one for psci-0.2 64-bit, and one for psci-0.1.
Maybe not though ... I'd have to think about it a bit more.

CHeers
---Dave