[PATCH 8/9] 8xx: Adder 875 support

[Scott Wood]

On Thu, Sep 06, 2007 at 10:57:28PM +0200, Segher Boessenkool wrote:
> >>>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."

You ignored the next sentence, which addressed exactly that point.

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

It says exactly that.  They used so many words like "generally",
"arbitrary", "no standard interpretation", "conventional usage", "might",
"for instance", "manufacturer-dependent", etc. that it's fairly clear
that they're merely providing hints as to how the property might be used.

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

"A manufacturer-dependent string that *generally* specifies the model
name and number".

Besides, that's what I did specify, plus the manufacturer.

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

Not for human consumption.

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

It matters because machine consumption is obviously not how this
particular model property is being used.

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

I am not going to add some completely useless layer of indirection
because it suits your odd interpretation of the standard.  The
/proc/cpuinfo output of the model property is useful.  Descriptive model
properties are useful.  Deal with it.

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

Whatever, you brought it up.

-Scott