Re: [PATCH v7 2/3] Documentation: dt: binding: fsl: Add 'little-endian' and update Chassis define

From: Scott Wood
Date: Thu Oct 24 2019 - 14:34:00 EST

On Mon, 2019-10-21 at 11:49 +0800, Ran Wang wrote:
> By default, QorIQ SoC's RCPM register block is Big Endian. But
> there are some exceptions, such as LS1088A and LS2088A, are
> Little Endian. So add this optional property to help identify
> them.
> Actually LS2021A and other Layerscapes won't totally follow Chassis
> 2.1, so separate them from powerpc SoC.

Did you mean LS1021A and "don't" instead of "won't", given the change to the

> Change in v5:
> - Add 'Reviewed-by: Rob Herring <robh@xxxxxxxxxx>' to commit message.
> - Rename property 'fsl,#rcpm-wakeup-cells' to '#fsl,rcpm-wakeup-
> cells'.
> please see

I'm not sure why Rob considers this the "correct form" -- there are other
examples of the current form, such as ibm,#dma-address-cells and ti,#tlb-
entries, and the current form makes more logical sense (# is part of the
property name, not the vendor). Oh well.

> Required properites:
> - reg : Offset and length of the register set of the RCPM block.
> - - fsl,#rcpm-wakeup-cells : The number of IPPDEXPCR register cells in the
> + - #fsl,rcpm-wakeup-cells : The number of IPPDEXPCR register cells in the
> fsl,rcpm-wakeup property.
> - compatible : Must contain a chip-specific RCPM block compatible string
> and (if applicable) may contain a chassis-version RCPM compatible
> @@ -20,6 +20,7 @@ Required properites:
> * "fsl,qoriq-rcpm-1.0": for chassis 1.0 rcpm
> * "fsl,qoriq-rcpm-2.0": for chassis 2.0 rcpm
> * "fsl,qoriq-rcpm-2.1": for chassis 2.1 rcpm
> + * "fsl,qoriq-rcpm-2.1+": for chassis 2.1+ rcpm

Is there something actually called "2.1+"? It looks a bit like an attempt to
claim compatibility with all future versions. If the former, is it a name
that comes from the hardware side with an intent for it to describe a stable
interface, or are we later going to see a patch changing some by-then-existing
device trees from "2.1+" to "2.1++" when some new incompatibility is found?

Perhaps it would be better to bind to the specific chip compatibles.