[PATCH][v3] dt-bindings: ifc: Update endianness usage

[Prabhakar Kushwaha]

> -----Original Message-----
> From: Rob Herring [mailto:robh at kernel.org]
> Sent: Tuesday, December 05, 2017 2:17 AM
> To: Prabhakar Kushwaha <prabhakar.kushwaha at nxp.com>
> Cc: devicetree at vger.kernel.org; mark.rutland at arm.com;
> shawnguo at kernel.org; linux-arm-kernel at lists.infradead.org
> Subject: Re: [PATCH][v3] dt-bindings: ifc: Update endianness usage
> 
> On Thu, Nov 30, 2017 at 01:36:36PM +0530, Prabhakar Kushwaha wrote:
> > IFC controller version < 2.0 support IFC register access as
> > big endian. These controller version also require IFC NOR signals to
> > be connected in reverse order with NOR flash.
> >
> > IFC >= 2.0 is other way around.
> >
> > So updating IFC binding to take care of both using endianness field.
> >
> > Signed-off-by: Prabhakar Kushwaha <prabhakar.kushwaha at nxp.com>
> > ---
> > Changes for v2: updated subject
> > Changes for v3: fixed typo for "big-endian"
> >
> >  Documentation/devicetree/bindings/memory-controllers/fsl/ifc.txt | 6 ++++--
> >  1 file changed, 4 insertions(+), 2 deletions(-)
> >
> > diff --git a/Documentation/devicetree/bindings/memory-controllers/fsl/ifc.txt
> b/Documentation/devicetree/bindings/memory-controllers/fsl/ifc.txt
> > index 89427b0..824a2ca 100644
> > --- a/Documentation/devicetree/bindings/memory-controllers/fsl/ifc.txt
> > +++ b/Documentation/devicetree/bindings/memory-controllers/fsl/ifc.txt
> > @@ -18,8 +18,10 @@ Properties:
> >                interrupt (NAND_EVTER_STAT).  If there is only one,
> >                that interrupt reports both types of event.
> >
> > -- little-endian : If this property is absent, the big-endian mode will
> > -                  be in use as default for registers.
> > +- little-endian or big-endian : It represents how IFC registers to be accessed.
> > +			It also represents connection between controller and
> > +			NOR flash. If this property is absent, the big-endian
> > +			mode will be in use as default.
> 
> My question on the prior version remains. I think if you need to handle
> more than just register endianness, that should be done with the
> compatible string.
> 

I may not able to use compatible string as this information will also be used it drivers/mtd/maps/physmap_of_core.c other than drivers/memory/fsl_ifc.c.
I am trying to avoid controller specific details in generic file. 

This is the reason endianness property is being used. 

--prabhakar