Subject: Re: [PATCH 2/6] PowerPC 440EPx: Sequoia DTS

From: David Gibson <[email-masked]>
Date: Wed, 8 Aug 2007 11:51:50 +1000

On Tue, Aug 07, 2007 at 06:33:01PM +0200, Segher Boessenkool wrote:
> >>>>> 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.

My thoughts exactly.

> >>> +    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.

Ok... should those really be separate properties, or should that go in
compatible, i.e. something like:
	compatible = "amd,XXXXXX", "jedec,a4-b7", "jedec-flash";

> >> 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.

Well.. not really policy enforcement, but a policy hint.

-- 
David Gibson			| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au	| minimalist, thank you.  NOT _the_ _other_
				| _way_ _around_!
http://www.ozlabs.org/~dgibson