[PATCH 2/6] PowerPC 440EPx: Sequoia DTS
Segher Boessenkool
segher at kernel.crashing.org
Wed Aug 8 02:33:01 EST 2007
>>>>> 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
More information about the Linuxppc-dev
mailing list