> -----Original Message----- > From: Scott Wood [mailto:oss@xxxxxxxxxxxx] > Sent: Wednesday, December 06, 2017 1:38 AM > To: Prabhakar Kushwaha <prabhakar.kushwaha@xxxxxxx>; linux- > mtd@xxxxxxxxxxxxxxxxxxx; devicetree@xxxxxxxxxxxxxxx > Cc: dedekind1@xxxxxxxxx; computersforpeace@xxxxxxxxx > 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@xxxxxxxxxxxx] > > > Sent: Tuesday, December 05, 2017 8:16 AM > > > To: Prabhakar Kushwaha <prabhakar.kushwaha@xxxxxxx>; linux- > > > mtd@xxxxxxxxxxxxxxxxxxx; devicetree@xxxxxxxxxxxxxxx > > > Cc: dedekind1@xxxxxxxxx; computersforpeace@xxxxxxxxx > > > 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 ��.n��������+%������w��{.n����z�{��ܨ}���Ơz�j:+v�����w����ޙ��&�)ߡ�a����z�ޗ���ݢj��w�f
