[PATCH 8/9] 8xx: Adder 875 support
scottwood at freescale.com
Fri Sep 7 07:30:23 EST 2007
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
> You cut that sentence short here, it continues: "as with the name
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.
More information about the Linuxppc-dev