linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: Segher Boessenkool <segher@kernel.crashing.org>
To: Scott Wood <scottwood@freescale.com>
Cc: linuxppc-dev@ozlabs.org
Subject: Re: [PATCH 8/9] 8xx: Adder 875 support
Date: Thu, 6 Sep 2007 22:57:28 +0200	[thread overview]
Message-ID: <143f0a1c76539260fd41fe953e6d1bdf@kernel.crashing.org> (raw)
In-Reply-To: <20070906195614.GA23333@ld0162-tx32.am.freescale.net>

>>> BTW, IEEE1275 seems to disagree:
>>
>> No it doesn't.
>
> "...in conventional usage the string begins with the name of the 
> device's
> manufacturer".

You cut that sentence short here, it continues: "as with the name
property."

> Even if you want to quibble about the manner in which the
> manufacturer is specified, that's quite different from leaving it out.

The text of the standard says that often people start the model
property contents with an "XYZ,".  It doesn't say that is required
(though it hints it might be a good idea to do so).  It doesn't say
it is okay to just put some arbitrary text there.

>> That would be "0ABCDEF,Adder MPC875" or "VWXYZ,Adder MPC875" --
>> not "some random string without a comma Adder MPC875".
>
> "the text string is arbitrary" and "conventional usage".

It doesn't say that.  It says _the format_ is arbitrary, it is
quite specific about the contents: model name and number.

> That "random string" is more useful for the intended purpose than the
> first half of a MAC address.

What, an OUI isn't useful for uniquely identifying a manufacturer?
That's news to me.

>> i.e., it is machine readable.
>
> No, it *can* be machine usable in certain circumstances.  I'm 100% sure
> that there is no code out there that cares what's in the model field of
> this board's device tree,

Why would that matter?

> other than to pass it to /proc/cpuinfo (i.e.
> human consumption).

It's not my fault that /proc/cpuinfo uses strings that are meant
for machine consumption by directly showing them to the user,
without some level of massaging by the platform code first.  It
definitely is no argument for doing bad things in your device
tree now, instead of fixing the kernel code.

Anyway, I've said enough about this, I think I've made my point --
and this is very minor stuff after all.


Segher

  reply	other threads:[~2007-09-06 20:57 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-09-05 19:27 [PATCH 1/9] 8xx: Fix CONFIG_PIN_TLB Scott Wood
2007-09-05 19:27 ` [PATCH 2/9] 8xx: Infrastructure code cleanup Scott Wood
2007-09-05 19:27 ` [PATCH 3/9] 8xx: Add pin and clock setting functions Scott Wood
2007-09-05 19:27 ` [PATCH 4/9] 8xx: Work around CPU15 erratum Scott Wood
2007-09-05 19:28 ` [PATCH 5/9] 8xx: Don't call non-existent Soft_emulate_8xx from SoftwareEmulation Scott Wood
2007-09-05 19:28 ` [PATCH 6/9] 8xx: Set initial memory limit Scott Wood
2007-09-05 19:28 ` [PATCH 7/9] 8xx: mpc885ads cleanup Scott Wood
2007-09-05 19:28 ` [PATCH 8/9] 8xx: Adder 875 support Scott Wood
2007-09-06 14:08   ` Segher Boessenkool
2007-09-06 14:16     ` Scott Wood
2007-09-06 17:50       ` Segher Boessenkool
2007-09-06 18:09         ` Scott Wood
2007-09-06 18:48           ` Segher Boessenkool
2007-09-06 19:12             ` Scott Wood
2007-09-06 19:20               ` Scott Wood
2007-09-06 19:36                 ` Segher Boessenkool
2007-09-06 19:56                   ` Scott Wood
2007-09-06 20:57                     ` Segher Boessenkool [this message]
2007-09-06 21:30                       ` Scott Wood
2007-09-06 23:45                         ` Olof Johansson
2007-09-06 19:32               ` Segher Boessenkool
2007-09-05 19:28 ` [PATCH 9/9] 8xx: Embedded Planet EP88xC support Scott Wood
2007-09-05 20:36 ` [PATCH 1/9] 8xx: Fix CONFIG_PIN_TLB Dan Malek
2007-09-05 20:53   ` Scott Wood
2007-09-05 20:59     ` Scott Wood
2007-09-05 22:27       ` Dan Malek
2007-09-06  3:11         ` Scott Wood
2007-09-05 22:08     ` Dan Malek
2007-09-05 22:23       ` Scott Wood
2007-09-05 22:42         ` Dan Malek
2007-09-06  3:01           ` Scott Wood

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=143f0a1c76539260fd41fe953e6d1bdf@kernel.crashing.org \
    --to=segher@kernel.crashing.org \
    --cc=linuxppc-dev@ozlabs.org \
    --cc=scottwood@freescale.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 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).