Hi Mark, Arnd

-----Original Message-----
From: Arnd Bergmann [mailto:arnd at arndb.de]
Sent: Thursday, September 04, 2014 3:09 PM
To: Mark Rutland
Cc: linux-arm-kernel at lists.infradead.org; rob.herring at linaro.org; Sharma
Bhupesh-B45370; Catalin Marinas; Will Deacon; Yoder Stuart-B08248;
grant.likely at secretlab.ca; Marc Zyngier; Basu Arnab-B45036; Geoff Levand
Subject: Re: [PATCH V3 0/6] ARM64: Add support for FSL's LS2085A SoC

On Thursday 04 September 2014 10:13:19 Mark Rutland wrote:

quoted

On Wed, Sep 03, 2014 at 07:31:44PM +0100, Arnd Bergmann wrote:

quoted

On Wednesday 03 September 2014 17:31:30 Mark Rutland wrote:

quoted

However, I'm not sure I follow the reasoning for making this
significantly harder, and even ignoring that I don't think this
does make things significantly harder. Especially so if we have a
PSCI node but not an enable method -- in that case its trivial to
patch in an unrelated enable-method anyhow.

Right, it's not actually much harder. A better way to look at it is
probably that we document what which parts we expect to stay
constant and which parts are to be filled out by the boot loader.
Independent of what PSCI implementation the boot loader provides, we
would like to see enable-method="psci".

So in the /cpus node, have a comment like:

/*
 * We expect the enable-method to be "psci", but this is dependent on
 * the FW, which will fill this in.
 */

I was thinking of leaving the enable-method in the cpus node, but having
an empty psci node with a similar comment.

quoted

Or, should we put together a soc-guidance.txt with that, ensuring
things are initialised correctly (CNTVOFF, CNTFREQ), etc?

I would very much welcome documentation like that!

Is this documentation planned (already being worked upon), or should I try to spin-out a RFC patch
which tries to add this guidance documentation.

Regards,
Bhupesh

quoted

quoted

I just saw that Geoff had a related comment, and documenting this
would make it clearer to other reviewers, as well as people that
happen to look at this file as a base for new platforms.

I agree that having something to point people in the right direction
is a good idea. The only point I disagree with is putitng something in
the DT that can be trivially made false (and possibly with good

reason).

quoted

I'm happy with having comments.

Right, but I see no good reason for having something else in the enable-
method, the only way I can see why that would be done is for the boot
loader or firmware implementer to be misinformed.

	Arnd