All of lore.kernel.org
 help / color / mirror / Atom feed
From: Scott Wood <oss-fOR+EgIDQEHk1uMJSBkQmQ@public.gmane.org>
To: Prabhakar Kushwaha
	<prabhakar.kushwaha-3arQi8VN3Tc@public.gmane.org>,
	"linux-mtd-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org"
	<linux-mtd-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org>,
	"devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
	<devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>
Cc: "dedekind1-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org"
	<dedekind1-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
	"computersforpeace-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org"
	<computersforpeace-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Subject: Re: [PATCH] Documentation: binding: Update endianness usage
Date: Tue, 05 Dec 2017 14:07:39 -0600	[thread overview]
Message-ID: <1512504459.10062.9.camel@buserror.net> (raw)
In-Reply-To: <HE1PR04MB1241ADD02E472BA492AE1C8F973D0-6LN7OEpIatU9TB6uw0n1oM9NdZoXdze2vxpqHgZTriW3zl9H0oFU5g@public.gmane.org>

On Tue, 2017-12-05 at 09:45 +0000, Prabhakar Kushwaha wrote:
> > -----Original Message-----
> > From: Scott Wood [mailto:oss-fOR+EgIDQEHk1uMJSBkQmQ@public.gmane.org]
> > Sent: Tuesday, December 05, 2017 8:16 AM
> > To: Prabhakar Kushwaha <prabhakar.kushwaha-3arQi8VN3Tc@public.gmane.org>; linux-
> > mtd-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org; devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> > Cc: dedekind1-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org; computersforpeace-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org
> > 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

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

WARNING: multiple messages have this Message-ID (diff)
From: Scott Wood <oss@buserror.net>
To: Prabhakar Kushwaha <prabhakar.kushwaha@nxp.com>,
	"linux-mtd@lists.infradead.org" <linux-mtd@lists.infradead.org>,
	"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>
Cc: "dedekind1@gmail.com" <dedekind1@gmail.com>,
	"computersforpeace@gmail.com" <computersforpeace@gmail.com>
Subject: Re: [PATCH] Documentation: binding: Update endianness usage
Date: Tue, 05 Dec 2017 14:07:39 -0600	[thread overview]
Message-ID: <1512504459.10062.9.camel@buserror.net> (raw)
In-Reply-To: <HE1PR04MB1241ADD02E472BA492AE1C8F973D0@HE1PR04MB1241.eurprd04.prod.outlook.com>

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

  parent reply	other threads:[~2017-12-05 20:07 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-11-29 11:27 [PATCH] Documentation: binding: Update endianness usage Prabhakar Kushwaha
2017-12-01  5:13 ` Scott Wood
2017-12-01  8:42   ` Prabhakar Kushwaha
2017-12-01 21:55     ` Scott Wood
2017-12-04  4:33       ` Prabhakar Kushwaha
2017-12-05  2:45         ` Scott Wood
2017-12-05  2:45           ` Scott Wood
     [not found]           ` <1512441957.10062.6.camel-fOR+EgIDQEHk1uMJSBkQmQ@public.gmane.org>
2017-12-05  9:45             ` Prabhakar Kushwaha
2017-12-05  9:45               ` Prabhakar Kushwaha
     [not found]               ` <HE1PR04MB1241ADD02E472BA492AE1C8F973D0-6LN7OEpIatU9TB6uw0n1oM9NdZoXdze2vxpqHgZTriW3zl9H0oFU5g@public.gmane.org>
2017-12-05 20:07                 ` Scott Wood [this message]
2017-12-05 20:07                   ` Scott Wood
2017-12-06 10:35                   ` Prabhakar Kushwaha
2017-12-06 10:35                     ` Prabhakar Kushwaha
2017-12-06 10:58                     ` Prabhakar Kushwaha
2017-12-06 10:58                       ` Prabhakar Kushwaha
     [not found]                       ` <HE1PR04MB124174461F845000614CDAA197320-6LN7OEpIatU9TB6uw0n1oM9NdZoXdze2vxpqHgZTriW3zl9H0oFU5g@public.gmane.org>
2017-12-21  5:20                         ` Prabhakar Kushwaha
2017-12-21  5:20                           ` Prabhakar Kushwaha
     [not found]                           ` <HE1PR04MB124148862807D5BD05E4E5AF970D0-6LN7OEpIatU9TB6uw0n1oM9NdZoXdze2vxpqHgZTriW3zl9H0oFU5g@public.gmane.org>
2018-01-10  8:47                             ` Prabhakar Kushwaha
2018-01-10  8:47                               ` Prabhakar Kushwaha

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1512504459.10062.9.camel@buserror.net \
    --to=oss-for+egidqehk1umjsbkqmq@public.gmane.org \
    --cc=computersforpeace-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \
    --cc=dedekind1-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \
    --cc=devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=linux-mtd-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org \
    --cc=prabhakar.kushwaha-3arQi8VN3Tc@public.gmane.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.