[PATCH] Documentation: binding: Update endianness usage

[PATCH] Documentation: binding: Update endianness usage

[Prabhakar Kushwaha]

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@nxp.com>
---
 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-endin : 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.
 
 - ranges : Each range corresponds to a single chipselect, and covers
            the entire access window as configured.
-- 
1.9.1

Re: [PATCH] Documentation: binding: Update endianness usage

[Scott Wood]

On Wed, 2017-11-29 at 16:57 +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@nxp.com>
> ---
>  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-endin : 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.

"endin"?

If big endian is the default, is this change really necessary?  Particularly
since the big endian chips are older and thus have existing device trees.

-Scott

RE: [PATCH] Documentation: binding: Update endianness usage

[Prabhakar Kushwaha]

> -----Original Message-----
> From: Scott Wood [mailto:oss@buserror.net]
> Sent: Friday, December 01, 2017 10:43 AM
> To: Prabhakar Kushwaha <prabhakar.kushwaha@nxp.com>; linux-
> mtd@lists.infradead.org; devicetree-discuss@lists.ozlabs.org
> Cc: dedekind1@gmail.com; computersforpeace@gmail.com
> Subject: Re: [PATCH] Documentation: binding: Update endianness usage
> 
> On Wed, 2017-11-29 at 16:57 +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@nxp.com>
> > ---
> >  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-endin : 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.
> 
> "endin"?
> 
> If big endian is the default, is this change really necessary?  Particularly
> since the big endian chips are older and thus have existing device trees.
> 

Earlier endianness information was only used for "how to"  access IFC-NAND register access.
Now this info  will also be used for defining swap requirement of NOR flash. 

As per my understanding, this "new usage type" should be updated in binding. 

"If this property is absent,  the big-  endian mode will be in use as default ". This line can be removed. 
Please let me know your view on this. 

--prabhakar

Re: [PATCH] Documentation: binding: Update endianness usage

[Scott Wood]

On Fri, 2017-12-01 at 08:42 +0000, Prabhakar Kushwaha wrote:
> > -----Original Message-----
> > From: Scott Wood [mailto:oss@buserror.net]
> > Sent: Friday, December 01, 2017 10:43 AM
> > To: Prabhakar Kushwaha <prabhakar.kushwaha@nxp.com>; linux-
> > mtd@lists.infradead.org; devicetree-discuss@lists.ozlabs.org
> > Cc: dedekind1@gmail.com; computersforpeace@gmail.com
> > Subject: Re: [PATCH] Documentation: binding: Update endianness usage
> > 
> > On Wed, 2017-11-29 at 16:57 +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@nxp.com>
> > > ---
> > >  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-endin : 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.
> > 
> > "endin"?
> > 
> > If big endian is the default, is this change really
> > necessary?  Particularly
> > since the big endian chips are older and thus have existing device trees.
> > 
> 
> Earlier endianness information was only used for "how to"  access IFC-NAND
> register access.
> Now this info  will also be used for defining swap requirement of NOR
> flash. 

Is this a difference between LS1021A and PPC-based chips?

> "If this property is absent,  the big-  endian mode will be in use as
> default ". This line can be removed. 
> Please let me know your view on this. 

No, it cannot be removed because there are existing device trees with IFC
nodes that don't have either property.

-Scott

RE: [PATCH] Documentation: binding: Update endianness usage

[Prabhakar Kushwaha]

> -----Original Message-----
> From: Scott Wood [mailto:oss@buserror.net]
> Sent: Saturday, December 02, 2017 3:25 AM
> To: Prabhakar Kushwaha <prabhakar.kushwaha@nxp.com>; linux-
> mtd@lists.infradead.org; devicetree-discuss@lists.ozlabs.org
> Cc: dedekind1@gmail.com; computersforpeace@gmail.com
> Subject: Re: [PATCH] Documentation: binding: Update endianness usage
> 
> On Fri, 2017-12-01 at 08:42 +0000, Prabhakar Kushwaha wrote:
> > > -----Original Message-----
> > > From: Scott Wood [mailto:oss@buserror.net]
> > > Sent: Friday, December 01, 2017 10:43 AM
> > > To: Prabhakar Kushwaha <prabhakar.kushwaha@nxp.com>; linux-
> > > mtd@lists.infradead.org; devicetree-discuss@lists.ozlabs.org
> > > Cc: dedekind1@gmail.com; computersforpeace@gmail.com
> > > Subject: Re: [PATCH] Documentation: binding: Update endianness usage
> > >
> > > On Wed, 2017-11-29 at 16:57 +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@nxp.com>
> > > > ---
> > > >  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-endin : 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.
> > >
> > > "endin"?
> > >
> > > If big endian is the default, is this change really
> > > necessary?  Particularly
> > > since the big endian chips are older and thus have existing device trees.
> > >
> >
> > Earlier endianness information was only used for "how to"  access IFC-NAND
> > register access.
> > Now this info  will also be used for defining swap requirement of NOR
> > flash.
> 
> Is this a difference between LS1021A and PPC-based chips?
> 

Yes. 
CONFIG_MTD_CFI_BE_BYTE_SWAP needs to be defined For LS1021A, LS1043A, LS1046A  

> > "If this property is absent,  the big-  endian mode will be in use as
> > default ". This line can be removed.
> > Please let me know your view on this.
> 
> No, it cannot be removed because there are existing device trees with IFC
> nodes that don't have either property.
> 

Go it. I will not remove it. Means patch remains same.

--prabhakar

Re: [PATCH] Documentation: binding: Update endianness usage

[Scott Wood]

On Mon, 2017-12-04 at 04:33 +0000, Prabhakar Kushwaha wrote:
> > -----Original Message-----
> > From: Scott Wood [mailto:oss@buserror.net]
> > Sent: Saturday, December 02, 2017 3:25 AM
> > To: Prabhakar Kushwaha <prabhakar.kushwaha@nxp.com>; linux-
> > mtd@lists.infradead.org; devicetree-discuss@lists.ozlabs.org
> > Cc: dedekind1@gmail.com; computersforpeace@gmail.com
> > Subject: Re: [PATCH] Documentation: binding: Update endianness usage
> > 
> > On Fri, 2017-12-01 at 08:42 +0000, Prabhakar Kushwaha wrote:
> > > > -----Original Message-----
> > > > From: Scott Wood [mailto:oss@buserror.net]
> > > > Sent: Friday, December 01, 2017 10:43 AM
> > > > To: Prabhakar Kushwaha <prabhakar.kushwaha@nxp.com>; linux-
> > > > mtd@lists.infradead.org; devicetree-discuss@lists.ozlabs.org
> > > > Cc: dedekind1@gmail.com; computersforpeace@gmail.com
> > > > Subject: Re: [PATCH] Documentation: binding: Update endianness usage
> > > > 
> > > > If big endian is the default, is this change really
> > > > necessary?  Particularly
> > > > since the big endian chips are older and thus have existing device
> > > > trees.
> > > > 
> > > 
> > > Earlier endianness information was only used for "how to"  access IFC-
> > > NAND
> > > register access.
> > > Now this info  will also be used for defining swap requirement of NOR
> > > flash.
> > 
> > Is this a difference between LS1021A and PPC-based chips?
> > 
> 
> Yes. 
> CONFIG_MTD_CFI_BE_BYTE_SWAP needs to be defined For LS1021A, LS1043A,
> LS1046A  

Only because you're running a little-endian kernel on those chips.  I still
don't see why the absence of a little-endian property isn't sufficient to
communicate that the hardware is big-endian given that that's the established
default.

I now see your patch to of_flash_probe... where is the non-IFC-specific
binding that says the *parent* of a CFI node should be looked at for this? 
Where in general are endian properties kept in the parent of the node with
"reg"?  The right answer is to add endianness to mtd-physmap.txt.

-Scott

RE: [PATCH] Documentation: binding: Update endianness usage

[Prabhakar Kushwaha]

> -----Original Message-----
> From: Scott Wood [mailto:oss@buserror.net]
> Sent: Tuesday, December 05, 2017 8:16 AM
> To: Prabhakar Kushwaha <prabhakar.kushwaha@nxp.com>; linux-
> mtd@lists.infradead.org; devicetree@vger.kernel.org
> Cc: dedekind1@gmail.com; computersforpeace@gmail.com
> Subject: Re: [PATCH] Documentation: binding: Update endianness usage
> 
> On Mon, 2017-12-04 at 04:33 +0000, Prabhakar Kushwaha wrote:
> > > -----Original Message-----
> > > From: Scott Wood [mailto:oss@buserror.net]
> > > Sent: Saturday, December 02, 2017 3:25 AM
> > > To: Prabhakar Kushwaha <prabhakar.kushwaha@nxp.com>; linux-
> > > mtd@lists.infradead.org; devicetree-discuss@lists.ozlabs.org
> > > Cc: dedekind1@gmail.com; computersforpeace@gmail.com
> > > Subject: Re: [PATCH] Documentation: binding: Update endianness usage
> > >
> > > On Fri, 2017-12-01 at 08:42 +0000, Prabhakar Kushwaha wrote:
> > > > > -----Original Message-----
> > > > > From: Scott Wood [mailto:oss@buserror.net]
> > > > > Sent: Friday, December 01, 2017 10:43 AM
> > > > > To: Prabhakar Kushwaha <prabhakar.kushwaha@nxp.com>; linux-
> > > > > mtd@lists.infradead.org; devicetree-discuss@lists.ozlabs.org
> > > > > Cc: dedekind1@gmail.com; computersforpeace@gmail.com
> > > > > Subject: Re: [PATCH] Documentation: binding: Update endianness usage
> > > > >
> > > > > If big endian is the default, is this change really
> > > > > necessary?  Particularly
> > > > > since the big endian chips are older and thus have existing device
> > > > > trees.
> > > > >
> > > >
> > > > Earlier endianness information was only used for "how to"  access IFC-
> > > > NAND
> > > > register access.
> > > > Now this info  will also be used for defining swap requirement of NOR
> > > > flash.
> > >
> > > Is this a difference between LS1021A and PPC-based chips?
> > >
> >
> > Yes.
> > CONFIG_MTD_CFI_BE_BYTE_SWAP needs to be defined For LS1021A, LS1043A,
> > LS1046A
> 
> Only because you're running a little-endian kernel on those chips.  I still
> don't see why the absence of a little-endian property isn't sufficient to
> communicate that the hardware is big-endian given that that's the established
> default.
> 
> I now see your patch to of_flash_probe... where is the non-IFC-specific
> binding that says the *parent* of a CFI node should be looked at for this?
> Where in general are endian properties kept in the parent of the node with
> "reg"?  The right answer is to add endianness to mtd-physmap.txt.
> 

Flashes are always littler endian. 
It is because of IFC controller behavior, endianness is required.  
So as per my understanding, this info should go in IFC binding. 

Please help me if I am not able to understand your view.

--prabhakar

Re: [PATCH] Documentation: binding: Update endianness usage

[Scott Wood]

On Tue, 2017-12-05 at 09:45 +0000, Prabhakar Kushwaha wrote:
> > -----Original Message-----
> > From: Scott Wood [mailto:oss@buserror.net]
> > Sent: Tuesday, December 05, 2017 8:16 AM
> > To: Prabhakar Kushwaha <prabhakar.kushwaha@nxp.com>; linux-
> > mtd@lists.infradead.org; devicetree@vger.kernel.org
> > Cc: dedekind1@gmail.com; computersforpeace@gmail.com
> > Subject: Re: [PATCH] Documentation: binding: Update endianness usage
> > 
> > I now see your patch to of_flash_probe... where is the non-IFC-specific
> > binding that says the *parent* of a CFI node should be looked at for this?
> > Where in general are endian properties kept in the parent of the node with
> > "reg"?  The right answer is to add endianness to mtd-physmap.txt.
> > 
> 
> Flashes are always littler endian. 

We wouldn't be having this discussion if that were true...  This is about how
it presents to the CPU, not about how the actual pins on the chip are
numbered.

> It is because of IFC controller behavior, endianness is required.  
> So as per my understanding, this info should go in IFC binding. 

If the info should go in the IFC binding why is the code in a non-IFC-specific 
place?

-Scott

RE: [PATCH] Documentation: binding: Update endianness usage

[Prabhakar Kushwaha]

> -----Original Message-----
> From: Scott Wood [mailto:oss@buserror.net]
> Sent: Wednesday, December 06, 2017 1:38 AM
> To: Prabhakar Kushwaha <prabhakar.kushwaha@nxp.com>; linux-
> mtd@lists.infradead.org; devicetree@vger.kernel.org
> Cc: dedekind1@gmail.com; computersforpeace@gmail.com
> Subject: Re: [PATCH] Documentation: binding: Update endianness usage
> 
> On Tue, 2017-12-05 at 09:45 +0000, Prabhakar Kushwaha wrote:
> > > -----Original Message-----
> > > From: Scott Wood [mailto:oss@buserror.net]
> > > Sent: Tuesday, December 05, 2017 8:16 AM
> > > To: Prabhakar Kushwaha <prabhakar.kushwaha@nxp.com>; linux-
> > > mtd@lists.infradead.org; devicetree@vger.kernel.org
> > > Cc: dedekind1@gmail.com; computersforpeace@gmail.com
> > > Subject: Re: [PATCH] Documentation: binding: Update endianness usage
> > >
> > > I now see your patch to of_flash_probe... where is the non-IFC-specific
> > > binding that says the *parent* of a CFI node should be looked at for this?
> > > Where in general are endian properties kept in the parent of the node with
> > > "reg"?  The right answer is to add endianness to mtd-physmap.txt.
> > >
> >
> > Flashes are always littler endian.
> 
> We wouldn't be having this discussion if that were true...  This is about how
> it presents to the CPU, not about how the actual pins on the chip are
> numbered.
> 

Got your point :)

> > It is because of IFC controller behavior, endianness is required.
> > So as per my understanding, this info should go in IFC binding.
> 
> If the info should go in the IFC binding why is the code in a non-IFC-specific
> place?
> 

Now I understand your point.  
So I should be moving endianness property detail in mtd-physmap.txt. 

Is my understanding correct?

--prabhakar

RE: [PATCH] Documentation: binding: Update endianness usage

[Prabhakar Kushwaha]

> -----Original Message-----
> From: Prabhakar Kushwaha
> Sent: Wednesday, December 06, 2017 4:05 PM
> To: 'Scott Wood' <oss@buserror.net>; linux-mtd@lists.infradead.org;
> devicetree@vger.kernel.org
> Cc: dedekind1@gmail.com; computersforpeace@gmail.com
> Subject: RE: [PATCH] Documentation: binding: Update endianness usage
> 
> 
> > -----Original Message-----
> > From: Scott Wood [mailto:oss@buserror.net]
> > Sent: Wednesday, December 06, 2017 1:38 AM
> > To: Prabhakar Kushwaha <prabhakar.kushwaha@nxp.com>; linux-
> > mtd@lists.infradead.org; devicetree@vger.kernel.org
> > Cc: dedekind1@gmail.com; computersforpeace@gmail.com
> > Subject: Re: [PATCH] Documentation: binding: Update endianness usage
> >
> > On Tue, 2017-12-05 at 09:45 +0000, Prabhakar Kushwaha wrote:
> > > > -----Original Message-----
> > > > From: Scott Wood [mailto:oss@buserror.net]
> > > > Sent: Tuesday, December 05, 2017 8:16 AM
> > > > To: Prabhakar Kushwaha <prabhakar.kushwaha@nxp.com>; linux-
> > > > mtd@lists.infradead.org; devicetree@vger.kernel.org
> > > > Cc: dedekind1@gmail.com; computersforpeace@gmail.com
> > > > Subject: Re: [PATCH] Documentation: binding: Update endianness usage
> > > >
> > > > I now see your patch to of_flash_probe... where is the non-IFC-specific
> > > > binding that says the *parent* of a CFI node should be looked at for this?
> > > > Where in general are endian properties kept in the parent of the node with
> > > > "reg"?  The right answer is to add endianness to mtd-physmap.txt.
> > > >
> > >
> > > Flashes are always littler endian.
> >
> > We wouldn't be having this discussion if that were true...  This is about how
> > it presents to the CPU, not about how the actual pins on the chip are
> > numbered.
> >
> 
> Got your point :)
> 
> > > It is because of IFC controller behavior, endianness is required.
> > > So as per my understanding, this info should go in IFC binding.
> >
> > If the info should go in the IFC binding why is the code in a non-IFC-specific
> > place?
> >
> 
> Now I understand your point.
> So I should be moving endianness property detail in mtd-physmap.txt.
> 
> Is my understanding correct?
> 

A second thought,  
IFC binding was updated because there is no IFC-NOR driver. It uses generic Flash framework.  
 
I am just trying to get more understanding.  

--prabhakar

RE: [PATCH] Documentation: binding: Update endianness usage

[Prabhakar Kushwaha]

Hi Scott,


> -----Original Message-----
> From: devicetree-owner@vger.kernel.org [mailto:devicetree-
> owner@vger.kernel.org] On Behalf Of Prabhakar Kushwaha
> Sent: Wednesday, December 06, 2017 4:29 PM
> To: Scott Wood <oss@buserror.net>; linux-mtd@lists.infradead.org;
> devicetree@vger.kernel.org
> Cc: dedekind1@gmail.com; computersforpeace@gmail.com
> Subject: RE: [PATCH] Documentation: binding: Update endianness usage
> 
> 
> 
> > -----Original Message-----
> > From: Prabhakar Kushwaha
> > Sent: Wednesday, December 06, 2017 4:05 PM
> > To: 'Scott Wood' <oss@buserror.net>; linux-mtd@lists.infradead.org;
> > devicetree@vger.kernel.org
> > Cc: dedekind1@gmail.com; computersforpeace@gmail.com
> > Subject: RE: [PATCH] Documentation: binding: Update endianness usage
> >
> >
> > > -----Original Message-----
> > > From: Scott Wood [mailto:oss@buserror.net]
> > > Sent: Wednesday, December 06, 2017 1:38 AM
> > > To: Prabhakar Kushwaha <prabhakar.kushwaha@nxp.com>; linux-
> > > mtd@lists.infradead.org; devicetree@vger.kernel.org
> > > Cc: dedekind1@gmail.com; computersforpeace@gmail.com
> > > Subject: Re: [PATCH] Documentation: binding: Update endianness usage
> > >
> > > On Tue, 2017-12-05 at 09:45 +0000, Prabhakar Kushwaha wrote:
> > > > > -----Original Message-----
> > > > > From: Scott Wood [mailto:oss@buserror.net]
> > > > > Sent: Tuesday, December 05, 2017 8:16 AM
> > > > > To: Prabhakar Kushwaha <prabhakar.kushwaha@nxp.com>; linux-
> > > > > mtd@lists.infradead.org; devicetree@vger.kernel.org
> > > > > Cc: dedekind1@gmail.com; computersforpeace@gmail.com
> > > > > Subject: Re: [PATCH] Documentation: binding: Update endianness usage
> > > > >
> > > > > I now see your patch to of_flash_probe... where is the non-IFC-specific
> > > > > binding that says the *parent* of a CFI node should be looked at for this?
> > > > > Where in general are endian properties kept in the parent of the node
> with
> > > > > "reg"?  The right answer is to add endianness to mtd-physmap.txt.
> > > > >
> > > >
> > > > Flashes are always littler endian.
> > >
> > > We wouldn't be having this discussion if that were true...  This is about how
> > > it presents to the CPU, not about how the actual pins on the chip are
> > > numbered.
> > >
> >
> > Got your point :)
> >
> > > > It is because of IFC controller behavior, endianness is required.
> > > > So as per my understanding, this info should go in IFC binding.
> > >
> > > If the info should go in the IFC binding why is the code in a non-IFC-specific
> > > place?
> > >
> >
> > Now I understand your point.
> > So I should be moving endianness property detail in mtd-physmap.txt.
> >
> > Is my understanding correct?
> >
> 
> A second thought,
> IFC binding was updated because there is no IFC-NOR driver. It uses generic Flash
> framework.
> 
> I am just trying to get more understanding.
> 

Do you have any comment/concern on this patch.
May I go ahead and request for the merger of updated patch i.e. https://patchwork.kernel.org/patch/10084331/

--prabhakar 

RE: [PATCH] Documentation: binding: Update endianness usage

[Prabhakar Kushwaha]

Hi Scott,
> -----Original Message-----
> From: Prabhakar Kushwaha
> Sent: Thursday, December 21, 2017 10:50 AM
> To: Prabhakar Kushwaha <prabhakar.kushwaha@nxp.com>; Scott Wood
> <oss@buserror.net>; linux-mtd@lists.infradead.org; devicetree@vger.kernel.org
> Cc: dedekind1@gmail.com; computersforpeace@gmail.com
> Subject: RE: [PATCH] Documentation: binding: Update endianness usage
> 
> Hi Scott,
> 
> 
> > -----Original Message-----
> > From: devicetree-owner@vger.kernel.org [mailto:devicetree-
> > owner@vger.kernel.org] On Behalf Of Prabhakar Kushwaha
> > Sent: Wednesday, December 06, 2017 4:29 PM
> > To: Scott Wood <oss@buserror.net>; linux-mtd@lists.infradead.org;
> > devicetree@vger.kernel.org
> > Cc: dedekind1@gmail.com; computersforpeace@gmail.com
> > Subject: RE: [PATCH] Documentation: binding: Update endianness usage
> >
> >
> >
> > > -----Original Message-----
> > > From: Prabhakar Kushwaha
> > > Sent: Wednesday, December 06, 2017 4:05 PM
> > > To: 'Scott Wood' <oss@buserror.net>; linux-mtd@lists.infradead.org;
> > > devicetree@vger.kernel.org
> > > Cc: dedekind1@gmail.com; computersforpeace@gmail.com
> > > Subject: RE: [PATCH] Documentation: binding: Update endianness usage
> > >
> > >
> > > > -----Original Message-----
> > > > From: Scott Wood [mailto:oss@buserror.net]
> > > > Sent: Wednesday, December 06, 2017 1:38 AM
> > > > To: Prabhakar Kushwaha <prabhakar.kushwaha@nxp.com>; linux-
> > > > mtd@lists.infradead.org; devicetree@vger.kernel.org
> > > > Cc: dedekind1@gmail.com; computersforpeace@gmail.com
> > > > Subject: Re: [PATCH] Documentation: binding: Update endianness usage
> > > >
> > > > On Tue, 2017-12-05 at 09:45 +0000, Prabhakar Kushwaha wrote:
> > > > > > -----Original Message-----
> > > > > > From: Scott Wood [mailto:oss@buserror.net]
> > > > > > Sent: Tuesday, December 05, 2017 8:16 AM
> > > > > > To: Prabhakar Kushwaha <prabhakar.kushwaha@nxp.com>; linux-
> > > > > > mtd@lists.infradead.org; devicetree@vger.kernel.org
> > > > > > Cc: dedekind1@gmail.com; computersforpeace@gmail.com
> > > > > > Subject: Re: [PATCH] Documentation: binding: Update endianness usage
> > > > > >
> > > > > > I now see your patch to of_flash_probe... where is the non-IFC-specific
> > > > > > binding that says the *parent* of a CFI node should be looked at for
> this?
> > > > > > Where in general are endian properties kept in the parent of the node
> > with
> > > > > > "reg"?  The right answer is to add endianness to mtd-physmap.txt.
> > > > > >
> > > > >
> > > > > Flashes are always littler endian.
> > > >
> > > > We wouldn't be having this discussion if that were true...  This is about how
> > > > it presents to the CPU, not about how the actual pins on the chip are
> > > > numbered.
> > > >
> > >
> > > Got your point :)
> > >
> > > > > It is because of IFC controller behavior, endianness is required.
> > > > > So as per my understanding, this info should go in IFC binding.
> > > >
> > > > If the info should go in the IFC binding why is the code in a non-IFC-specific
> > > > place?
> > > >
> > >
> > > Now I understand your point.
> > > So I should be moving endianness property detail in mtd-physmap.txt.
> > >
> > > Is my understanding correct?
> > >
> >
> > A second thought,
> > IFC binding was updated because there is no IFC-NOR driver. It uses generic
> Flash
> > framework.
> >
> > I am just trying to get more understanding.
> >
> 
> Do you have any comment/concern on this patch.
> May I go ahead and request for the merger of updated patch i.e.
> https://patchwork.kernel.org/patch/10084331/
> 

Please let me know if you have any concern on this patch. 

--prabhakar