[PATCH 1/2] Documentation: devicetree: arm: cpus/cpu nodes bindings updates

On Fri, Sep 13, 2013 at 09:51:56PM +0100, Rob Herring wrote:

On 09/13/2013 11:57 AM, Lorenzo Pieralisi wrote:

quoted

Hi Rob, all,

On Thu, Aug 15, 2013 at 04:22:38PM +0100, Lorenzo Pieralisi wrote:

quoted

[adding Andrew, Gregory and Thomas to check the Marvell compatible names]

On Thu, Aug 15, 2013 at 03:32:05PM +0100, Rob Herring wrote:

quoted

On 08/15/2013 04:42 AM, Lorenzo Pieralisi wrote:

quoted

In order to extend the current cpu nodes bindings to newer CPUs
inclusive of AArch64 and to update support for older ARM CPUs this
patch updates device tree documentation for the cpu nodes bindings.

Main changes:
    - adds 64-bit bindings
    - define usage of #address-cells
    - defines behaviour on pre and post v7 uniprocessor systems
    - adds ARM 11MPcore specific reg property definition

Signed-off-by: Lorenzo Pieralisi <redacted>
---
 Documentation/devicetree/bindings/arm/cpus.txt | 424 ++++++++++++++++++++++---
 1 file changed, 377 insertions(+), 47 deletions(-)

The binding looks mostly fine to me.

These bindings have still not received an ACK, and need review by
Marvell guys in copy for the new compatible strings below.

If you can't get comment, then leave them out if they are not used
already. If they are used, then tough shit when they want to change.

quoted

Most importantly, we need to make a decision on the pre v7 uniprocessor
systems, where MPIDR/CPUID are non-existent and the reg property is a
pure SW enumeration. Current bindings (ie this patch) define

#address-cells = <0>;

for those processors (and there are a number of dts in the kernel with that
set-up); Grant and Benjamin had a strong feeling against this choice, I
have to make a decision on how to proceed, please let me know.

I agree that we should define #address-cells to 1 and reg will be simply
0,1,2,etc. in this case.

Ok, so this means that when these bindings are finally acked and queued
for merging, there will be a slew of dts in the kernel that will need
patching (again) and this is likely to ruffle feathers. Honestly I would
leave this task to platform maintainers, if we all agree.

This change and fixing the example as I pointed out are what I was
waiting to see.

Perfect, given that I got feedback from Andrew, I will be posting a
final version very soon.

Lorenzo