All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mitch Bradley <wmb@firmworks.com>
To: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: linuxppc-dev list <linuxppc-dev@ozlabs.org>,
	devicetree-discuss@lists.ozlabs.org
Subject: Re: [RFC] Clock binding
Date: Thu, 27 Aug 2009 12:28:17 -1000	[thread overview]
Message-ID: <4A970881.5090603@firmworks.com> (raw)
In-Reply-To: <1251411532.20467.74.camel@pasglop>

>
>
>> > Open Firmware often avoids indexed structures.  Cases in point include 
>> > the use of named properties instead of fixed structures and named 
>> > methods instead of function pointer arrays.  Open Firmware's use of 
>> > arrays for reg properties seems like the right choice for that 
>> > particular case, but shouldn't be construed to suggest that arrays are 
>> > good for everything.
>>     
>
> Well, the "reg" property is fine for the common cases of devices with
> one IO (or MMIO) range, no confusion possible, or PCI since it encodes
> the BAR number. For other cases, especially random embedded stuff that
> maps several regions of memory, it's a bit harder since we go back to
> the need of having "somebody" define which region is which.
>
>
>   

Indeed.  You choose based on the common case and eventually there will 
be some case that stretches the boundaries.

I suppose that, if the problem became severe enough, one could invent a 
new "reg-names" property, a list of strings naming the reg entries.

WARNING: multiple messages have this Message-ID (diff)
From: Mitch Bradley <wmb-D5eQfiDGL7eakBO8gow8eQ@public.gmane.org>
To: Benjamin Herrenschmidt
	<benh-XVmvHMARGAS8U2dJNN8I7kB+6BGkLq7r@public.gmane.org>
Cc: linuxppc-dev list
	<linuxppc-dev-mnsaURCQ41sdnm+yROfE0A@public.gmane.org>,
	devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org
Subject: Re: [RFC] Clock binding
Date: Thu, 27 Aug 2009 12:28:17 -1000	[thread overview]
Message-ID: <4A970881.5090603@firmworks.com> (raw)
In-Reply-To: <1251411532.20467.74.camel@pasglop>

>
>
>> > Open Firmware often avoids indexed structures.  Cases in point include 
>> > the use of named properties instead of fixed structures and named 
>> > methods instead of function pointer arrays.  Open Firmware's use of 
>> > arrays for reg properties seems like the right choice for that 
>> > particular case, but shouldn't be construed to suggest that arrays are 
>> > good for everything.
>>     
>
> Well, the "reg" property is fine for the common cases of devices with
> one IO (or MMIO) range, no confusion possible, or PCI since it encodes
> the BAR number. For other cases, especially random embedded stuff that
> maps several regions of memory, it's a bit harder since we go back to
> the need of having "somebody" define which region is which.
>
>
>   

Indeed.  You choose based on the common case and eventually there will 
be some case that stretches the boundaries.

I suppose that, if the problem became severe enough, one could invent a 
new "reg-names" property, a list of strings naming the reg entries.

  reply	other threads:[~2009-08-27 22:28 UTC|newest]

Thread overview: 47+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-08-18  4:21 [RFC] Clock binding Benjamin Herrenschmidt
2009-08-18  4:21 ` Benjamin Herrenschmidt
2009-08-18  7:45 ` [RFC/PATCH] Clock binding prototype implementation Benjamin Herrenschmidt
2009-08-18  7:45   ` Benjamin Herrenschmidt
2009-08-27  4:09 ` [RFC] Clock binding Benjamin Herrenschmidt
2009-08-27  4:09   ` Benjamin Herrenschmidt
2009-08-27  5:20   ` Grant Likely
2009-08-27 21:11   ` Mitch Bradley
2009-08-27 21:11     ` Mitch Bradley
2009-08-27 22:18     ` Benjamin Herrenschmidt
2009-08-27 22:18       ` Benjamin Herrenschmidt
2009-08-27 22:28       ` Mitch Bradley [this message]
2009-08-27 22:28         ` Mitch Bradley
2009-08-27 22:45       ` Mitch Bradley
2009-08-27 22:45         ` Mitch Bradley
2009-08-28  0:51         ` Benjamin Herrenschmidt
2009-08-28  0:51           ` Benjamin Herrenschmidt
2009-08-28  2:36           ` Mitch Bradley
2009-08-28  2:36             ` Mitch Bradley
2009-08-28  2:43             ` Benjamin Herrenschmidt
2009-08-28  2:43               ` Benjamin Herrenschmidt
2009-08-28  2:53               ` Michael Ellerman
2009-08-28  2:53                 ` Michael Ellerman
2009-08-28 10:58               ` Josh Boyer
2009-08-28 11:23                 ` David Gibson
2009-08-28 11:23                   ` David Gibson
2009-08-28 22:28                   ` Benjamin Herrenschmidt
2009-08-28 22:28                     ` Benjamin Herrenschmidt
2009-08-28 12:16               ` Stuart Yoder
2009-08-28 12:16                 ` Stuart Yoder
2009-08-28 16:06                 ` Grant Likely
2009-08-28 16:06                   ` Grant Likely
2009-08-28 18:05                   ` Stuart Yoder
2009-08-28 18:05                     ` Stuart Yoder
2009-08-28 18:23                     ` M. Warner Losh
2009-08-28 18:23                       ` M. Warner Losh
2009-08-28 20:09                     ` Grant Likely
2009-08-28 20:09                       ` Grant Likely
2009-08-31 17:49                       ` Stuart Yoder
2009-08-31 17:49                         ` Stuart Yoder
2009-08-28 18:12                   ` Mitch Bradley
2009-08-28 18:12                     ` Mitch Bradley
2009-08-28 18:24                   ` Rafal Jaworowski
2009-08-28 22:33                     ` Benjamin Herrenschmidt
2009-08-28 22:33                       ` Benjamin Herrenschmidt
2009-08-28 16:37 ` Grant Likely
2009-08-28 16:37   ` Grant Likely

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=4A970881.5090603@firmworks.com \
    --to=wmb@firmworks.com \
    --cc=benh@kernel.crashing.org \
    --cc=devicetree-discuss@lists.ozlabs.org \
    --cc=linuxppc-dev@ozlabs.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.