Messages in this thread | | | From | Scott Wood <> | Date | Thu, 24 Oct 2019 13:33:45 -0500 | Subject | Re: [PATCH v7 2/3] Documentation: dt: binding: fsl: Add 'little-endian' and update Chassis define |
| |
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?
> Change in v5: > - Add 'Reviewed-by: Rob Herring <robh@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.
-Scott
| |