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

[Ran Wang]

Hi Scott,

On Friday, October 25, 2019 02:34, Scott Wood wrote
> 
> 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
> examples?

OK, I will change it to don't to just tel current situation.
 
> > Change in v5:
> > 	- Add 'Reviewed-by: Rob Herring <robh at kernel.org>' to commit
> message.
> > 	- Rename property 'fsl,#rcpm-wakeup-cells' to '#fsl,rcpm-wakeup-
> > cells'.
> > 	please see https://lore.kernel.org/patchwork/patch/1101022/
> 
> 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.

According to SoC data sheets, powerPC SoC T1040 and current ARM based Layerscape
SoCs (LS1021A, LS1012A, LS1043A, etc)'s arch designs are both basing on Chassis spec 2.1.
However, for Layerscape, their data sheets are also explicitly telling that some minor
changes have been made(basing on Chassis 2.1 spec). And in parallel, the SW arch designs
between T1040 and Layerscape family are also different: For Layerscape, part of RCPM
programming job has been moved from kernel driver to firmware/bootloader (through
PSCI interface). That's why I have to name a new compatible string to distinguish them.
They cannot use the same driver. I don’t think we will add another sting like 2.1++ in the
future. If the Chassis spec keep evolving and requiring different programming logic,
we can add more like 3.0, 4.0, ..., I think.

Regards,
Ran