Thread (30 messages) 30 messages, 6 authors, 2014-09-24
STALE4290d
Revisions (6)
  1. v3 [diff vs current]
  2. v3 [diff vs current]
  3. v3 [diff vs current]
  4. v3 current
  5. v3 [diff vs current]
  6. v7 [diff vs current]

[PATCH V3 0/6] ARM64: Add support for FSL's LS2085A SoC

From: mark.rutland@arm.com (Mark Rutland)
Date: 2014-09-04 09:13:19

On Wed, Sep 03, 2014 at 07:31:44PM +0100, Arnd Bergmann wrote:
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.
 */

Or, should we put together a soc-guidance.txt with that, ensuring things
are initialised correctly (CNTVOFF, CNTFREQ), etc?
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).

I'm happy with having comments.

Mark.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help