On Wednesday 03 September 2014 17:09:36 Mark Rutland wrote:

On Wed, Sep 03, 2014 at 05:05:51PM +0100, Arnd Bergmann wrote:

quoted

On Wednesday 03 September 2014 16:56:55 Mark Rutland wrote:

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).

Ok, I see the appeal in forcing boot loaders to put some patch
up the dtbs with whatever software interfaces they provide.
What I'm interested in however is making it harder for the boot
loader to use something other than psci.

How about setting enable-method=psci but not providing a psci node?
That way the boot loader still has to patch up the psci node but
not necessarily each CPU node, unless they want to use the spin table,
which they should not.

	Arnd