>>>>> Yeah, better names please -- if possible, something that someone >>>>> without knowledge of this SoC will understand what it is. >>>> >>>> I think the names are probably ok - I'm assuming they're in keeping >>>> with the convention I've used of using the same names / >>>> abbreviations >>>> as in the CPU user manual. I'm asking just for my own information, >>>> although a comment might not be a bad idea. >> >> Fine with me -- I personally prefer "system-device-controller" >> and "clock-power-controller" or similar, but that is mostly a >> matter of taste. As long as it's human readable it's fine. > > Actually, it occurs to me that I've only sometimes been using that > convention for the names: basically just for the weirdo chip control > devices that don't have a more widespread generic name.
It's pretty darn hard to make good sensible "generic names" for some of the devices on a SoC; using the acronym that's in the documentation for that SoC certainly isn't the worst choice. >>> + Flash partitions >>> + - reg : >>> + - read-only : (optional) >> >> I'll hold off commenting on this until you've finish writing it, >> you probably know my opinion about it anyway :-) > > Heh.. actually I was kind of hoping for your input on what's still > missing. For example, I don't know what the necessary extra > properties for JEDEC chips are. I meant for the "partitions" stuff only. For the JEDEC chips, we need a "vendor-id" and "device-id" property at least (or similar names -- whatever is general practice for this); both are a single byte, encoded as with encode-int. >> One thing though -- what _exactly_ does "read-only" signify? > > That's... a good question. Yeah. It seems to me that the way it is currently used is pure policy enforcement, which doesn't belong in the device tree. Segher _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
