[PATCH] Documentation: binding: Update endianness usage

Prabhakar Kushwaha prabhakar.kushwaha at nxp.com
Wed Dec 6 02:35:26 PST 2017


> -----Original Message-----
> From: Scott Wood [mailto:oss at buserror.net]
> Sent: Wednesday, December 06, 2017 1:38 AM
> To: Prabhakar Kushwaha <prabhakar.kushwaha at nxp.com>; linux-
> mtd at lists.infradead.org; devicetree at vger.kernel.org
> Cc: dedekind1 at gmail.com; computersforpeace at 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 at buserror.net]
> > > Sent: Tuesday, December 05, 2017 8:16 AM
> > > To: Prabhakar Kushwaha <prabhakar.kushwaha at nxp.com>; linux-
> > > mtd at lists.infradead.org; devicetree at vger.kernel.org
> > > Cc: dedekind1 at gmail.com; computersforpeace at 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




More information about the linux-mtd mailing list