linuxppc-dev.lists.ozlabs.org archive mirror
 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:45:25 -1000	[thread overview]
Message-ID: <4A970C85.8090703@firmworks.com> (raw)
In-Reply-To: <1251411532.20467.74.camel@pasglop>

>
>> > One advantage of indices is that they avoid endless arguments about the 
>> > exact name (and spelling) of things.
>>     
>
> Right, though in that case, nobody gets to have to decide on the name,
> it comes from the chip manufacturer pin naming or data sheet.
>
>   


I agree in general.  It has long been a convention of mine to follow the 
vendor's names as exactly as possible.  But that often presents 
difficulties. Many of them have been touched on in our previous 
discussion but I'll list some here just to emphasize the problem we face:

a) Inconsistent naming within a vendor's documentation set - datasheet 
spells it one way, programmer's manual another, appnotes/porting guide 
still another, reference schematic spells it two different ways (pin 
name on part versus net name of signal wire).

b) Sometimes the name is abbreviated and sometimes spelled out.  SMBALRT 
vs. SMbus Alert.

c) Different tools (CAD programs, word processors) have different 
conventions leading to existence of ambiguously-representable name 
components - particular cases in point are overbars for active low 
signals and embedded spaces/underscores/hyphens in names.

d) Compatible part from different vendors leads to confusion about which 
vendor's names are canonical.  Or leading vendor goes out of business or 
gets bought.

These problems are getting worse rapidly as more devices are being 
sourced from Asia, where the linguistic connection to the Roman alphabet 
is tenuous.

You need a Pope to decide what is canonical.

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

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-08-18  4:21 [RFC] Clock binding Benjamin Herrenschmidt
2009-08-18  7:45 ` [RFC/PATCH] Clock binding prototype implementation Benjamin Herrenschmidt
2009-08-27  4:09 ` [RFC] Clock binding Benjamin Herrenschmidt
2009-08-27  5:20   ` Grant Likely
2009-08-27 21:11   ` Mitch Bradley
2009-08-27 22:18     ` Benjamin Herrenschmidt
2009-08-27 22:28       ` Mitch Bradley
2009-08-27 22:45       ` Mitch Bradley [this message]
2009-08-28  0:51         ` Benjamin Herrenschmidt
2009-08-28  2:36           ` Mitch Bradley
2009-08-28  2:43             ` Benjamin Herrenschmidt
2009-08-28  2:53               ` Michael Ellerman
2009-08-28 10:58               ` Josh Boyer
2009-08-28 11:23                 ` David Gibson
2009-08-28 22:28                   ` Benjamin Herrenschmidt
2009-08-28 12:16               ` Stuart Yoder
2009-08-28 16:06                 ` Grant Likely
2009-08-28 18:05                   ` Stuart Yoder
2009-08-28 18:23                     ` M. Warner Losh
2009-08-28 20:09                     ` Grant Likely
2009-08-31 17:49                       ` Stuart Yoder
2009-08-28 18:12                   ` Mitch Bradley
2009-08-28 18:24                   ` Rafal Jaworowski
2009-08-28 22:33                     ` Benjamin Herrenschmidt
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=4A970C85.8090703@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).