Thread (30 messages) 30 messages, 6 authors, 2014-09-24
STALE4280d
Revisions (6)
  1. v3 [diff vs current]
  2. v3 current
  3. v3 [diff vs current]
  4. v3 [diff vs 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-03 16:09:36

On Wed, Sep 03, 2014 at 05:05:51PM +0100, Arnd Bergmann wrote:
On Wednesday 03 September 2014 16:56:55 Mark Rutland wrote:
quoted
I had asked for the FW to patch up the enable-method (and omit this in
the in-kernel dts) as this is something that may vary over the lifetime
of the SoC independently from the fixed HW properties (it's a firmware
property really).
I agree in principle.
Ok.
 
quoted
Personally I'd like to see such things patched by the firmware/loader
where possible (ideally with some way of switching said patching off if
we really know better). We already expect the loader to patch memory
nodes where memory can be dynamically populated. 

I don't see why we should tie the in-kernel dts to a particular firmware
revision. Having such properties in the in-kernel dts is only going to
mislead. The arm64 boot-wrapper patches dts for PSCI, but for
compatibility with old wrappers the in-kernel dts must forever say
spin-table is used to bring up secondaries.
But the kernel has never supported this platform with a non-PSCI
enable method, why should we provide compatibility for something
we never had upstream?
I'm not arguing we should.

What I'm suggesting is there wouldn't be an enable-method at all (so we
won't bring up secondaries at all unless that's patched).

I didn't spot an enable-method in skimming this series, but I've not yet
looked at this posting in-depth. Assuming there isn't one I don't see
that we're providing compatibility with anything.

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