All of lore.kernel.org
 help / color / mirror / Atom feed
From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: Olof Johansson <olof@lixom.net>
Cc: Tomasz Figa <tomasz.figa@gmail.com>,
	frowand.list@gmail.com, Stephen Warren <swarren@wwwdotorg.org>,
	"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
	Linux Kernel list <linux-kernel@vger.kernel.org>,
	Marek Szyprowski <m.szyprowski@samsung.com>,
	Stephen Warren <swarren@nvidia.com>,
	Rob Herring <rob.herring@calxeda.com>,
	Grant Likely <grant.likely@secretlab.ca>
Subject: Re: "memory" binding issues
Date: Wed, 18 Sep 2013 09:04:20 +1000	[thread overview]
Message-ID: <1379459060.6148.10.camel@pasglop> (raw)
In-Reply-To: <CAOesGMjt6RsvYRjXxpB=v-Ro6iyUN=YzkDd1mfHqCDJJDRJvLg@mail.gmail.com>

On Tue, 2013-09-17 at 14:33 -0700, Olof Johansson wrote:
> > I don't think it's broken, why do you think so? It's at least
> consistent.
> > Probably not perfect and not complete, but IMHO a reasonable base
> for
> > further work. (Also at least something written down that people can
> learn
> > from and/or refer to.)
> 
> So, I stand corrected. It seems that at least one legacy system I'm
> looking at always specifies unit address as well. I don't like it but
> I'll stop arguing.
> 
> Ben: The interesting part is that it does _not_ specify it on /memory
> though. Nor, of course, on /cpus or /openprom. So assuming /memory@0
> exists will break even on some powerpc platforms.

What system is that out of curiosity ? Also make sure it's not just
Linux being an idiot and stripping the @0 in /proc/device-tree ...

(I think some old versions of /proc code would strip it)

Or is that some insanely broken OF like Apple old world or Pegasos ?

If it's just embedded .dts files, yes, I fixed some, but we might still
have some bad ones. 

In any case, we all agree, the right thing to do first is to fix our
path parser to cope either way.

Cheers,
Ben.



WARNING: multiple messages have this Message-ID (diff)
From: Benjamin Herrenschmidt <benh-XVmvHMARGAS8U2dJNN8I7kB+6BGkLq7r@public.gmane.org>
To: Olof Johansson <olof-nZhT3qVonbNeoWH0uzbU5w@public.gmane.org>
Cc: Tomasz Figa <tomasz.figa-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
	frowand.list-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org,
	Stephen Warren <swarren-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>,
	"devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
	<devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
	Linux Kernel list
	<linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
	Marek Szyprowski
	<m.szyprowski-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>,
	Stephen Warren <swarren-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>,
	Rob Herring <rob.herring-bsGFqQB8/DxBDgjK7y7TUQ@public.gmane.org>,
	Grant Likely
	<grant.likely-s3s/WqlpOiPyB63q8FvJNQ@public.gmane.org>
Subject: Re: "memory" binding issues
Date: Wed, 18 Sep 2013 09:04:20 +1000	[thread overview]
Message-ID: <1379459060.6148.10.camel@pasglop> (raw)
In-Reply-To: <CAOesGMjt6RsvYRjXxpB=v-Ro6iyUN=YzkDd1mfHqCDJJDRJvLg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>

On Tue, 2013-09-17 at 14:33 -0700, Olof Johansson wrote:
> > I don't think it's broken, why do you think so? It's at least
> consistent.
> > Probably not perfect and not complete, but IMHO a reasonable base
> for
> > further work. (Also at least something written down that people can
> learn
> > from and/or refer to.)
> 
> So, I stand corrected. It seems that at least one legacy system I'm
> looking at always specifies unit address as well. I don't like it but
> I'll stop arguing.
> 
> Ben: The interesting part is that it does _not_ specify it on /memory
> though. Nor, of course, on /cpus or /openprom. So assuming /memory@0
> exists will break even on some powerpc platforms.

What system is that out of curiosity ? Also make sure it's not just
Linux being an idiot and stripping the @0 in /proc/device-tree ...

(I think some old versions of /proc code would strip it)

Or is that some insanely broken OF like Apple old world or Pegasos ?

If it's just embedded .dts files, yes, I fixed some, but we might still
have some bad ones. 

In any case, we all agree, the right thing to do first is to fix our
path parser to cope either way.

Cheers,
Ben.


--
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

  reply	other threads:[~2013-09-17 23:04 UTC|newest]

Thread overview: 54+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-09-16  2:57 "memory" binding issues Benjamin Herrenschmidt
2013-09-16  2:57 ` Benjamin Herrenschmidt
2013-09-16 15:22 ` Kumar Gala
2013-09-16 15:22   ` Kumar Gala
2013-09-16 22:42   ` Benjamin Herrenschmidt
2013-09-17 15:53     ` Kumar Gala
2013-09-17 15:53       ` Kumar Gala
2013-09-16 16:17 ` Stephen Warren
2013-09-16 16:17   ` Stephen Warren
2013-09-16 22:46   ` Benjamin Herrenschmidt
2013-09-16 22:46     ` Benjamin Herrenschmidt
2013-09-16 22:48     ` Olof Johansson
2013-09-16 22:48       ` Olof Johansson
2013-09-16 23:47       ` Benjamin Herrenschmidt
2013-09-16 23:47         ` Benjamin Herrenschmidt
2013-09-16 23:48         ` Olof Johansson
2013-09-17  1:37           ` Benjamin Herrenschmidt
2013-09-17  1:37             ` Benjamin Herrenschmidt
2013-09-17  7:56       ` Tomasz Figa
2013-09-17  7:56         ` Tomasz Figa
2013-09-17 16:43         ` Olof Johansson
2013-09-17 16:43           ` Olof Johansson
2013-09-17 21:08           ` Frank Rowand
2013-09-17 21:08             ` Frank Rowand
2013-09-17 21:15             ` Olof Johansson
2013-09-17 21:15               ` Olof Johansson
2013-09-17 21:19               ` Tomasz Figa
2013-09-17 21:19                 ` Tomasz Figa
2013-09-17 21:33                 ` Olof Johansson
2013-09-17 23:04                   ` Benjamin Herrenschmidt [this message]
2013-09-17 23:04                     ` Benjamin Herrenschmidt
2013-09-17 23:25                     ` Olof Johansson
2013-09-17 23:25                       ` Olof Johansson
2013-09-17 21:56               ` Benjamin Herrenschmidt
2013-09-17 21:56                 ` Benjamin Herrenschmidt
2013-09-18 16:28               ` Stephen Warren
2013-09-18 16:28                 ` Stephen Warren
2013-09-19  0:29                 ` David Gibson
2013-09-19  0:29                   ` David Gibson
2013-09-18  1:25             ` David Gibson
2013-09-18  1:25               ` David Gibson
2013-09-18  1:31         ` Grant Likely
2013-09-18  1:31           ` Grant Likely
2013-09-18  1:38     ` Grant Likely
2013-09-18  8:08       ` Benjamin Herrenschmidt
2013-09-18  8:08         ` Benjamin Herrenschmidt
2013-09-18  2:57 ` Grant Likely
2013-09-18  2:57   ` Grant Likely
2013-09-18  8:21   ` Benjamin Herrenschmidt
2013-09-18  8:21     ` Benjamin Herrenschmidt
2013-09-27 15:42     ` Kumar Gala
2013-09-27 15:42       ` Kumar Gala
2013-10-03 15:04       ` Kumar Gala
  -- strict thread matches above, loose matches on Subject: below --
2013-09-16  2:41 Benjamin Herrenschmidt

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=1379459060.6148.10.camel@pasglop \
    --to=benh@kernel.crashing.org \
    --cc=devicetree@vger.kernel.org \
    --cc=frowand.list@gmail.com \
    --cc=grant.likely@secretlab.ca \
    --cc=linux-kernel@vger.kernel.org \
    --cc=m.szyprowski@samsung.com \
    --cc=olof@lixom.net \
    --cc=rob.herring@calxeda.com \
    --cc=swarren@nvidia.com \
    --cc=swarren@wwwdotorg.org \
    --cc=tomasz.figa@gmail.com \
    /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.