On Wed, Oct 22, 2008 at 02:09:01PM -0500, Matt Sealey wrote: > Anton Vorontsov wrote: >> On Wed, Oct 22, 2008 at 01:40:50PM -0500, Matt Sealey wrote: >> >> I think I got it. ;-) You think that I'm not aware of that we _can_ >> use the device_type for matching the nodes. Well, I'm aware of it, >> sure we can. ;-) > > I'm sure you are aware, I am just a little jumpy regarding this as the > whole ePAPR-is-official thing and the direction Linux is taking with > regards to redefining part of the device tree specs, that this could have > been something a little more serious :) > >> But we don't use it for the rtc nodes, and we don't want to encourage >> the usage for the flat trees. And that's the point of this patch. > > Would it not be prudent to, while not actively encouraging it, at least > mention device_type in any specifications as a legacy item (for real Open > Firmware only) and for if a device should be in the tree as a generic, > IEEE 1275-style device (i.e. there would be a set of well-defined client > interface methods for it in a real OF)? > > My basic concerns are for input/output as reported by /chosen - in case > it is important exactly what is being used, there is at least one > out-of-driver code snippet which checks if stdin and stdout are of type > "serial" (or "failsafe") and auto-directs console to that - it would be > nice to keep this clean and not dump a million serial-device-compatibles > in another list here if someone wants to automatically choose between > console output on the DIU or PSC for MPC5121e/MPC8610 for example, or > wants to restrict the amount of fancy stuff it does on a terminal if it's > a slow serial device, or perhaps even automatically invoke netconsole if > it's set to "network"? > > I know U-Boot doesn't have the intelligence to output to anything but a > serial port these days on those devices, but as they say, there is no > fate but what we make .. we should make sure it doesn't turn up that code > is never suggested or attempted because supporting it in Linux would be > too big a jump or too messy a patch :)
I don't feel competent to comment on "embedded-OF"/FDT design decisions... Let's Cc [EMAIL PROTECTED] ? -- Anton Vorontsov email: [EMAIL PROTECTED] irc://irc.freenode.net/bd2 _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev