I wholeheartedly agree, although the difference between gpt and timer
and pic vs interrupt-controller (actually interrupt-controller is meant
to be a property of the interrupt controller, not a device type.. weird)
was chosen because they did not conflict with what might be considered
"standard device_types" with real OF (Forth, CIS) interfaces like read,
write, ping, world-peace etc.

However since Linux doesn't care about the interface provided by the
firmware and only reads the tree, and real OF interfaces MIGHT need
to be provided by these items on real OF firmwares, I don't see why
they should not be used.

A problem arises; how do you decide when you name something after what
it is rather than the documentation acronym? What does the 5200B CDM
turn into? The XLB arbiter module? What about the rest of the SIU?

There really needs to be a standards committee for this, that has good
experience with device trees and BSPs, and can work with the device
vendors and board manufacturers (Freescale for example) directly, with
them on the committee, who can give the docs a run though before any
board ever hits the streets...

--
Matt Sealey <[EMAIL PROTECTED]>
Genesi, Manager, Developer Relations

Robert Schwebel wrote:
On Fri, Apr 18, 2008 at 09:10:04AM -0700, Grant Likely wrote:
Update dts files to current format

Is it somehow possible that this device tree stuff is *not* changed over
and over again and break everything out there? When people have not even
agreed on basic things like decimal vs. hex numbers, the whole idea
should be developed out-of-tree, then stabilize and *then* be submitted
to the Linux mainline.

Is it also really necessary to change like "gpt" vs. "timer" and "pic"
vs. "interrupt-controller" all the time? If you compare the last
mainline kernels, each one got a fundamental change in the naming, each
time breaking anyone who doesn't have his stuff in the mainline yet.

Sorry, but this is simply annoying, and the whole "the only thing we
have to do is to define it once and be done then" is crap.

Robert
_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Reply via email to